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Resumen 


La  importancia  de  los  videojuegos  en  la  sociedad  actual  está  fuera  de  toda  duda.  De 
hecho,  la  industria  del  videojuego  genera  al  año  mas  ingresos  que  la  del  cine  y  la  música 
juntas. 

Sin  embargo,  aunque  el  desarrollo  de  videojuegos  es  una  actividad  que  desde  el  punto  de 
vista  comercial  es  muy  interesante,  desde  el  punto  de  vista  del  desarrollo  es  muy  exigente, 
ya  que  involucra  una  gran  cantidad  de  disciplinas:  motor  del  juego,  físicas,  interfaces  de 
usuario,  inteligencia  artificial,  networking,  programación  gráfica,  programación  de  niveles, 
diseño  de  las  mecánicas  de  juego  (gameplay),  etc. 

Incluso  limitándonos  a  las  disciplinas  relacionadas  con  las  cuestiones  más  técnicas,  su 
dominio  requiere  años  de  experiencia  y  un  gran  nivel  de  especialización.  En  las  grandes 
compañías  de  desarrollo  existen  grupos  de  trabajo  con  objetivos  muy  concretos,  mientras 
que  en  las  pequeñas  compañías  los  desarrolladores  deben  aunar  conocimientos  de  diversas 
técnicas. 

En  este  contexto  tan  favorable,  en  el  que  el  sector  de  los  videojuegos  está  en  pleno  au¬ 
ge,  surge  el  proyecto  Tinman.  Ea  motivación  es  crear  un  videojuego  que  sirva  como  caso 
práctico,  un  ejemplo  funcional  fácil  de  estudiar  que  muestre  y  facilite  la  comprensión  de  los 
mecanismos  internos  del  mismo  a  los  profesionales  que  quieran  introducirse  en  el  sector  del 
videojuego,  algo  que  tiene  especial  valor  dada  la  naturaleza  reservada  de  esta  industria. 

Un  aspecto  novedoso  de  este  proyecto  es  la  implementación  de  una  serie  de  técnicas  de 
instrospección  e  instrumentación  del  motor  de  juego  que  han  permitido  crear  pruebas  au¬ 
tomáticas.  Dado  que  el  proceso  de  testing  en  videojuegos  pasa  por  jugar  una  y  otra  vez  al 
juego  que  se  está  desarrollando,  y  debido  a  la  enorme  complejidad  de  estos  proyectos,  el  uso 
de  testing  automático  tiene  especial  relevancia  para  reducir  costes  y  tiempo  de  desarrollo, 
permitiendo  la  detección  temprana  de  errores. 

El  videojuego  creado  es  un  clon  del  clásico  arcade  de  los  90’s  Super  OJfRoad.  Sin  embar¬ 
go,  atendiendo  a  las  demandas  del  mercado,  se  ha  implementado  un  modo  multijugador  en 
red  utilizando  ZeroC  Ice  como  middleware  de  comunicacione,  que  ha  ayudado  a  abstraer  los 
detalles  de  bajo  nivel.  Por  último  lado,  se  ofrece  también  la  posibilidad  de  juego  local  compi¬ 
tiendo  contra  Bots.  Para  ello  se  ha  creado  un  componente  de  inteligencia  artificial,  primando 
la  facilidad  para  integrar  nuevos  algoritmos  por  encima  de  la  complejidad  del  mismo. 
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Abstract 


The  relevance  of  the  videogames  in  nowday’s  society  is  out  of  doubt.  In  fact,  the  game 
industry  generales  more  income  per  year  than  the  film  and  music  industry  together. 

However,  although  the  development  of  video  games  is  a  very  interesting  activity  from  the 
commercial  point  of  view,  from  the  point  of  view  development  is  very  challenging  because 
it  involves  a  lot  of  disciplines:  game  engine,  physical,  user  interfaces,  artificial  intelligence, 
networking,  graphical  programming,  programming  levels,  design  game  mechanics  (game- 
play),  etc. 

Even  limiting  ourselves  to  the  more  technical  disciplines,  your  domain  requires  years  of 
experience  and  a  high  level  of  specialization.  In  large  videogame  companies  there  are  de¬ 
velopment  groups  with  very  specific  goals,  while  in  small  companies  their  developers  must 
combine  knowledge  of  various  techniques. 

In  this  so  favorable  context  ,  in  which  the  video  game  industry  is  in  booming,  is  where 
bom  is  the  project  Tinman  .  The  motivation  is  to  create  a  game  that  serve  as  a  study  case,  an 
easy  example  to  study  functional  to  show  and  facilitate  understanding  of  the  inner  workings 
to  those  professionals  who  want  to  enter  the  video  game  industry,  which  is  something  with 
added  valué  given  the  confidential  nature  of  this  industry. 

A  novel  aspect  of  this  project  is  the  implementation  of  a  series  of  introspection  techniques 
and  instrumentation  of  the  game  engine  that  allow  to  create  automated  tests.  Since  the  pro- 
cess  of  testing  in  videogames  consist  in  play  video  games  again  and  again  to  the  game  that  is 
being  developed,  and  due  to  the  enormous  complexity  of  these  projects,  the  use  of  automated 
testing  has  special  relevance  to  reduce  costs  and  development  time,  allowing  early  detection 
of  errors. 

The  game  created  is  a  clone  of  the  arcade  classic  90’s  emph  Super  Off  Road.  However, 
in  responso  to  market  demands,  it  has  been  implemented  multiplayer  mode  using  ZeroC  Ice 
as  communication  middleware,  which  has  helped  to  abstract  the  low-level  details.  Finally,  it 
also  offers  the  possibility  of  competing  against  local  game  Bots.  For  this  we  have  created  a 
component  of  artificial  intelligence,  giving  priority  easy  to  intégrate  new  algorithms  above 
complexity. 
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Capítulo  1 

Introducción 


La  importancia  de  los  videojuegos  en  la  sociedad  actual  está  fuera  de  toda  duda.  Tanto  es 
así,  que  un  estudio  publicado  por  la  empresa  Newzoo  [New  14]  afirma  que  el  mercado 
mundial  del  videojuego  alcanzará  en  2017  una  cifra  de  facturación  de  102900  millones 
de  dólares.  Aunque  se  trata  de  una  estimación  basada  en  la  tendencia  actual  del  mercado 
mundial,  es  suficiente  para  demostrar  la  enorme  importancia  que  tienen  los  videojuegos  en 
la  economía  mundial. 

Desde  el  punto  de  vista  del  desarrollo,  los  proyectos  de  este  tipo  están  caracterizados  por 
involucrar  una  gran  cantidad  de  disciplinas:  motor  del  juego,  físicas,  interfaces  de  usuario, 
inteligencia  artificial,  networking,  programación  gráfica,  programación  de  niveles,  diseño  de 
las  mecánicas  de  juego  (gameplay),  etc.  todo  esto  sin  contar  los  roles  no  relacionados  con  la 
programación,  como  los  artísticos  o  comerciales. 


Figura  1.1:  Visión  conceptual  de  un  equipo  de  desarrollo  de  videojuegos,  http://www.cedv. 
es/ 

Como  se  puede  ver,  el  desarrollo  de  videojuegos  supone  a  los  desarrolladores  dominar  una 
serie  de  disciplinas.  Incluso  limitándonos  a  las  relacionadas  con  las  cuestiones  más  técnicas, 
su  dominio  requiere  años  de  experiencia  y  un  gran  nivel  de  especialización.  En  las  gran¬ 
des  compañías  existen  grupos  de  trabajo  con  objetivos  muy  concretos,  mientras  que  en  las 
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pequeñas  compañías  los  desarrolladores  deben  aunar  conocimientos  de  diversas  técnicas. 

Además,  si  atendemos  a  las  demandas  del  mercado,  es  común  que  los  nuevos  títulos  in¬ 
cluyan  algún  modo  multijugador.  Los  modos  multijugador  ofrecen  un  gran  abanico  de  po¬ 
sibilidades,  ya  que  permiten  la  interacción  de  varios  jugadores  de  forma  simultánea,  lo  que 
aporta  un  componente  social  a  la  experiencia  de  juego.  Esto  significa  que  los  des  arrolladores 
deben  diseñar  e  implementar  el  modelo  de  red  del  videojuego.  Se  estudiarán  las  diferentes 
alternativas  tecnológicas  existentes  para  implementar  el  modelo  de  red  del  videojuego  en 
desarrollo. 

Por  otra  parte,  el  desarrollo  de  videojuegos  es  una  labor  muy  susceptible  a  errores.  Tener 
pruebas  que  ayuden  a  ver  que  el  código  que  vamos  generando  no  produce  conflictos  con 
el  previamente  existente  es  clave  a  la  hora  de  desarrollar  un  producto  de  mayor  calidad.  Se 
estudiará  la  forma  de  instrumentar  el  videojuego  que  se  desarrollará,  con  el  objetivo  de  hacer 
posible  crear  pruebas  pruebas  automáticas. 

Por  último,  hay  que  señalar  que  dado  que  la  creación  de  pruebas  automáticas  en  videojue¬ 
gos  es  algo  que  no  está  ampliamente  extendido,  esto  servirá  como  un  proceso  exploratorio 
que  permitirá  ver  hasta  qué  punto  es  posible  aplicar  técnicas  de  testing  automático  sobre  un 
videojuego. 

1.1  Estructura  del  documento 

A  continuación  se  explica  la  estructura  del  documento,  definiendo  el  contenido  de  cada 
uno  de  los  capítulos  que  lo  componen.  Por  otra  parte,  para  una  mejor  compresión  del  presente 
documento,  se  recomienda  al  lector  comenzar  la  lectura  por  el  capítulo  de  Objetivos,  tras  lo 
cuál  el  orden  puede  variar  dependiendo  de  los  conocimientos  del  lector. 

Si  el  lector  tiene  conocimientos  en  materia  de  desarrollo  de  videojuegos,  concretamente 
de  programación  en  red  y  desarrollo  de  la  Inteligencia  Artificial  (lA),  se  recomienda  que 
avance  directamente  al  capítulo  de  Desarrollo.  De  no  ser  así,  se  insta  al  lector  en  comenzar 
la  lectura  por  el  de  Antecedentes. 

Por  último  se  recomienda  leer  la  sección  de  Conclusiones  y  Trabajo  futuro. 

Capítulo  2:  Objetivos 

El  presente  proyecto  pretende  desarrollar  un  videojuego  3D,  con  soporte  de  red.  Este 
videojuego  servirá  como  base  sobre  el  que  experimentar  con  una  serie  de  técnicas  de 
testing  automático,  de  forma  que  sea  posible  ver  hasta  qué  punto  es  posible  aplicarlas. 

Capítulo  3:  Antecedentes 

En  este  capítulo  se  introduce  el  estado  del  arte,  desarrollando  los  aspectos  mas  rele¬ 
vantes  en  materia  de  desarrollo  de  videojuegos  y  tecnologías  relacionadas. 
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Capítulo  4:  Desarrollo  del  proyecto 

El  proyecto  ha  sido  dividido  en  iteraciones  para  abordar  su  desarrollo.  Al  final  de  cada 
una  de  esas  iteraciones  se  entrega  un  prototipo  añadiendo  la  funcionalidad  requerida. 
En  este  capítulo  se  describen  los  requisitos  que  debe  cumplir  el  proyecto  en  cada  una 
de  sus  iteraciones,  así  como  la  evolución  obtenida  en  cada  una  de  ellas.  Se  justifi¬ 
can  las  decisiones  que  se  han  tomado  durante  el  desarrollo,  así  como  los  aspectos  de 
implementación  mas  relevantes. 

Capítulo  5:  Arquitectura  del  Motor 

En  este  capítulo  se  explican  los  aspectos  mas  importantes  relativos  a  la  arquitectura 
del  motor  de  videojuegos  que  ha  emergido  como  resultado  de  este  proyecto. 

Capítulo  6:  Metodología  y  herramientas 

Debido  a  que  los  requisitos  pueden  cambiar  o  refinarse  durante  el  desarrollo  del  mis¬ 
mo,  se  ha  elegido  una  metodología  iterativa  e  incremental,  para  el  desarrollo  de  este 
proyecto  se  ha  decidido  utilizar  una  metodología  ágil  adaptada  a  las  necesidades  que 
han  surgido  a  lo  largo  del  desarrollo.  En  esencia,  consiste  en  una  metodología  iterativa 
e  incrementa,  con  la  que  se  ha  buscado  obtener  prototipos  funcionales  que  permitan 
ver  la  evolución  del  proyecto  en  cada  momento. 

Capítulo  7:  Conclusiones  y  trabajo  futuro 

Se  finaliza  este  documento  ofreciendo  las  conclusiones  que  se  han  alcanzado  tras  la 
finalización  del  proyecto.  Al  mismo  tiempo,  existe  un  gran  abanico  de  posibilidades 
referente  a  trabajo  futuro,  de  forma  que  se  expondrán  algunas  de  las  alternativas  mas 
interesantes. 


1.2  Repositorio,  Nombre  del  proyecto  y  página  web 

Este  proyecto  participó  en  el  IX  Concurso  Universitario  de  Software  libre.  Uno  de  los  re¬ 
quisitos  del  concurso  era  que  el  alumno  debía  crear  un  blog  y  asignar  un  nombre  al  proyecto. 
El  nombre  que  se  escogió  para  este  proyecto  fue  un  giño  al  juego  en  que  se  inspiró  el  dise¬ 
ño  de  este,  Super  OffRoad.  Una  de  las  versiones  de  dicho  juego  se  llamaba  Ivan  ’lronman’ 
Stewart’s  Super  OjfRoad  en  honor  a  dicho  piloto,  el  cuál  era  una  celebridad  en  este  tipo  de 
carreras.  Se  decidió  llamar  a  este  proyecto  Tinman  a  fin  de  hacer  una  pequeña  broma,  ya  que 
sería  como  el  hermano  pequeño  del  juego  anterior. 

Por  otra  parte,  el  blog  'traque  se  creó  sirvió  como  un  diario  donde  ir  registrando  el  avance 
del  proyecto.  En  él  se  puede  encontrar  una  serie  de  artículos  que  describen  aspectos  impor¬ 
tantes  del  desarrollo  así  como  la  documentación  creada  con  Doxygen. 

Por  último,  el  enlace  al  repositorio  de  este  proyecto  es  el  siguiente:  https  ;//bitbucket .  org/ 
a rco_group/tfg. tinman. 

^http  ://isaaclacoba . github . io/tinman/ 
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Capítulo  2 


Objetivos 


En  este  capítulo  se  enumeran  y  describen  los  objetivos  que  se  pretenden  cumplir  durante 
el  desarrollo  de  este  proyecto. 

2.1  Objetivo  general 

El  objetivo  principal  de  este  proyecto  consiste  en  desarrollar  un  videojuego  usando  gráfi¬ 
cos  3D,  que  disponga  de  un  modo  multijugador  en  red,  haciendo  énfasis  en  un  diseño  exten- 
sible  y  modular,  de  forma  que  se  cree  un  caso  práctico.  Será  importante  conseguir  un  código 
fuente  claro,  que  facilite  la  labor  de  estudiarlo,  modificarlo  y  extenderlo  a  programadores 
noveles  interesados  en  este  área. 

Debido  a  que  el  lenguaje  estándar  en  la  industria  del  videojuego  es  C-t-i-,  y  el  objetivo  últi¬ 
mo  de  este  proyecto  es  orientarlo  al  ámbito  docente,  se  ha  impuesto  el  requisito  no  funcional 
de  que  ese  sea  el  lenguaje  de  implementación.  Adicionalmente,  se  impone  un  segundo  requi¬ 
sito  no  funcional  consistente  en  utilizar  tecnologías  libres.  Por  esa  razón,  se  usará  OgreSD 
como  motor  de  renderizado. 

2.2  Objetivos  específicos 

A  continuación,  se  enumeran  y  describen  los  objetivos  concretos  del  proyecto: 

2.2.1  Objetivo  1 

Diseño  e  implementación  un  videojuego  completamente  funcional.  El  videojuego  debe 
cumplir  con  los  siguientes  requisitos: 

■  El  género  del  videojuego  será  de  «carreras  de  coches».  Ea  razones  son  que  éste  género 
favorece  un  desarrollo  iterativo,  ya  que  es  sencillo  añadir  nuevos  circuitos,  nuevos 
tipos  de  coches,  mas  modos  de  juegos(contrarreloj,  multijugador,  contra  la  máquina, 
etcétera). 

■  Utilización  de  gráficos  en  3D.  Se  hará  uso  de  animaciones,  efectos  de  partículas,  téc¬ 
nicas  de  iluminación  y  sombreado  dinámico,  overlays,  etcétera. 

■  Se  invertirán  esfuerzos  en  optimizar  el  rendimiento  del  juego.  Esto  se  verá  plasmado 
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en  la  velocidad  de  respuesta  del  mismo,  permitiendo  responder  en  tiempo  real  a  las 
entradas  del  jugador,  de  forma  que  este  pueda  interaccionar  con  el  videojuego  y,  por 
tanto,  conseguir  una  experiencia  de  juego  agradable. 

2.2.2  Objetivo  2 

Diseño  e  implementación  de  un  algoritmo  de  inteligencia  artificial,  que  haga  posible  un 
modo  de  juego  contra  la  máquina.  Los  requisitos  mínimos  del  algoritmo  son: 

■  que  permitan  a  un  coche  dar  una  vuelta  a  un  circuito,  en  un  tiempo  parecido  en  que  lo 
haría  un  jugador  humano. 

■  Debe  ser  independiente  del  trazado  del  circuito;  es  decir,  debe  ser  lo  suficientemente 
genérico  como  para  permitir  su  reutilización  entre  circuitos  sin  necesidad  de  ninguna 
modificación. 

■  Debe  ser  simple  y  fácil  de  entender  ya  que  el  objetivo  es  demostrar  cómo  se  integra  el 
algoritmo  con  el  motor  de  juego. 

2.2.3  Objetivo  3 

Diseño  e  implementación  de  mecanismos  de  instrumentación  del  juego  que  permite  apli¬ 
car  técnicas  de  testing  automático  y  al  mismo  tiempo  exponer  los  mecanismos  con  fines 
didácticos  y  de  depuración. 

2.2.4  Objetivo  4 

Diseño  e  implementación  de  un  modelo  de  red  para  una  modalidad  multijugador,  que 
aprovechará  los  citados  mecanismos  de  instrumentación  con  los  mismos  fines.  Los  requisitos 
mínimos  son: 

■  Debe  ser  posible  jugar  en  Local  Area  NetWork  (LAN)  de  forma  fluida,  de  tal  manera 
que  no  se  afecte  negativamente  a  la  experiencia  de  juego. 

■  El  juego  debe  poder  ser  jugado  en  red  al  menos  con  100  ms  de  falencia  y  con  una 
pérdida  máxima  de  paquetes  del  10  %,  de  forma  que  no  se  degrade  la  experiencia  de 
juego. 


6 


Capítulo  3 

Antecedentes 


En  este  eapítulo  se  realizará  un  estudio  de  las  teenologías  aetuales  utilizadas  en  el  desa¬ 
rrollo  de  videojuegos,  del  uso  de  téenieas  de  testing  automátiea  por  parte  de  las  empre¬ 
sas  del  seetor  y  de  las  diferentes  alternativas  existentes  a  la  hora  de  implementar  un  modelo 
de  red  en  un  videojuego  moderno. 

3.1  Motores  de  Juego 

A  la  hora  de  desarrollar  un  videojuego  hoy  en  día,  uno  de  los  primeros  pasos  eonsiste  en 
seleeeionar  la  teenología  sobre  la  que  apoyarse  a  la  hora  de  erear  eontenido.  Para  ello,  los 
equipo  de  trabajo  utilizan  lo  que  se  eonoee  eomo  motor  de  juego. 

Un  motor  de  juego  es  un  tipo  de  software  que  aúna,  en  un  únieo  programa,  todas  los 
módulos  neeesarios  para  gestionar  eada  uno  de  los  reeursos  eon  los  que  se  ereará  un  video¬ 
juego: 

■  Gestión  de  gráficos:  módulo  que  se  eneargará  de  gestionar  los  elementos  gráfieos  que 
eompondrán  el  mundo  del  videojuego.  Tiene  eomo  responsabilidad  renderizar  la  esee- 
na,  orear  sombras  dinámioas,  apliear  materiales  y  texturas  sobre  los  ouerpos  de  dieha 
esoena,  apliear  téenieas  de  iluminaeión,  gestionar  el  sistemas  de  partíoulas,  las  anima- 
oiones,  etoétera. 

■  Gestión  de  widgets  (Graphical  Control  Element):  módulo  que  se  enearga  de  orear  y 
gestionar  elementos  visuales  eon  los  que  eonformarán  las  interfaees  del  videojuego; 
por  ejemplo:  botones,  barras  de  progreso,  spinners,  eteétera. 

■  Gestión  de  eventos  de  entrada:  módulo  que  permite  eapturar  y  gestionar  los  eventos 
generados  por  los  periférioos  a  través  de  los  ouales  se  oomunioa  el  jugador  eon  el 
videojuego.  El  proeeso  de  gestión  puede  oonsistir  en  ejeeutar  una  funoión  asoeiada  a 
una  determinada  teela,  por  ejemplo. 

■  Gestión  de  sonidos:  módulo  encargado  de  reproducir  los  efectos  de  sonidos  producidos 
durante  la  ejecución  del  juego,  el  bucle  musical,  etcétera. 

■  Gestión  de  eventos  de  red:  módulo  encargado  de  administrar  las  comunicaciones  del 
videojuego.  Típicamente  dependerá  del  modelo  de  red  empleado  por  el  motor  de  red. 
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■  Gestión  de  físicas:  modulo  encargado  de  modelar  los  cuerpos  dentro  del  mundo  del 
vieojuego,  de  forma  que  se  comporten  de  forma  realista  de  acuerdo  a  unas  leyes  físicas. 
Actualmente  se  suelen  usar  las  leyes  de  Newton  para  modelar  las  interacciones  entre 
los  cuerpos.  Por  otra  parte  se  suele  asumir  que  se  tratan  de  cuerpos  rígidos,  aunque 
actualmente  gracias  al  incremento  en  la  potencia  del  hardware  se  está  empezando  a 
utilizar  cuerpos  fluidos. 

3.1.1  Motores  de  juegos  comerciales 

Como  se  puede  observar,  existe  una  gran  cantidad  de  elementos  que  deben  ser  controlados 
a  la  hora  de  crear  un  videojuego  de  calidad.  La  eficiencia  del  motor  de  juego  a  la  hora  de 
administrar  estos  recursos  es  vital  de  cara  a  conseguir  un  rendimiento  óptimo.  A  continuación 
se  compararán  los  principales  motores  de  juego  comerciales. 

A  la  hora  de  hablar  de  motores  de  juegos  comerciales,  existen  tres  grandes  favoritos: 
UnitySD,  Unreal  Engine  y  CryEngine.  A  continuación  se  expondrán  los  puntos  fuertes  de 
cada  uno. 

Unity3D  Pro 

Ea  mayor  baza  de  Unity  es  su  facilidad  de  uso.  Ofrece  un  editor  gráfico  que  permite  la 
creación  de  escenarios  de  una  forma  sencilla.  Por  otra  parte,  la  gran  cantidad  de  plataformas 
para  las  que  permite  exportar  los  videojuegos  ahorran  tiempo  de  desarrollo,  al  abstraer  de  los 
detalles  específicos  de  cada  plataforma. 

El  motor  soporta  assets  de  las  principales  aplicaciones  de  gráficos  3D  Max,  Maya,  Softi- 
mage,  CINEMA  4D,  Blender,  etcétera.  Con  la  versión  5  del  motor  se  han  añadido  caracte¬ 
rísticas  gráficas  como  shading  físico,  iluminación  en  tiempo  real,  reflejos  HDR,  etcétera. 

A  la  hora  de  programar,  Unity  ofrece  la  posibilidad  de  desarrollar  usando  C#,  Boo  (un 
lenguaje  con  sintaxis  similar  a  Python)  o  UnityScript  (un  lenguaje  personalizado  con  sintaxis 
inspirada  en  ECMAScript). 

Ea  versión  profesional  de  UnitySD  tiene  un  coste  de  1.500  $,  mas  1.500  $  para  poder 
exportar  videojuegos  a  android  y  otros  1.500  $  para  IOS.  Como  alternativa  ofrece  un  modelo 
de  subscripción  de  75  $  mensuales,  con  un  compromiso  de  permanencia  de  1  año.  Tras  el 
año,  se  da  la  opción  de  elegir  bien  comprar  la  versión  profesional  o  bien  seguir  usando  Unity 
con  la  versión  gratuita.  Ea  versión  profesional  tiene  un  coste  de  1.500  $  mas  3.000  $  si  se 
quiere  exportar  a  android  e  IOS  (esa  cantidad  por  cada  desarrollador  que  vaya  a  trabajar  con 
Unity3D  en  el  equipo^). 


'https://store.unity3d.com/ 
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Unreal  Engine  4 

Unreal  Engine  tiene  un  coste  de  19$  por  desarrollador  y  unas  tasas  del  5  %  de  los  be¬ 
neficios  totales.  La  subscripción  puede  ser  cancelada  en  cualquier  momento,  perdiendo  el 
derecho  a  recibir  actualizaciones  del  motor. 

El  motor  ofrece  acceso  al  código  fuente,  aunque  con  una  serie  restricciones^: 

■  No  se  puede  integrar  el  motor  con  software  que  tenga  una  licencia  copyleft.  Las  licen¬ 
cias  con  las  que  no  puede  trabajar  Unreal  Engine  son:  GPL,  LGPL  o  Creative  Com- 
mons  Attribution-ShareAlike  License. 

■  Sólo  permite  compartir  el  código  fuente  con  otros  usuarios  del  motor  que  tengan  ac¬ 
ceso  a  la  misma  versión  del  motor. 

■  Incluir  cualquier  parte  del  código  del  motor  hace  que  se  deban  pagar  las  tasas  antes 
mencionadas. 

■  Sólo  se  pueden  discutir  trozos  de  código  de  un  máximo  de  30  líneas  de  código  y  con 
el  único  interés  de  discutir  acerca  de  ese  trozo  de  código. 

En  cuanto  a  sus  capacidades  técnicas,  la  última  versión  del  motor  dispone  de  luces  dinámi¬ 
cas,  así  como  un  sistema  de  partículas  que  le  permite  manejar  hasta  un  millón  de  partículas 
en  escena  a  la  vez.  Esto  hace  posible  que  los  juegos  creados  con  este  motor  puedan  disfrutar 
de  gráficos  foto-realistas. 

Por  otra  parte,  Unreal  permite  al  desarrollador  programar  en  C-t-i-  y  en  Blueprint,  un  len¬ 
guaje  propio  de  prototipado. 

CryEngine 

Cry Engine  tiene  un  coste  de  10  $  al  mes  sin  ninguna  tasa  adicional,  lo  que  lo  convierte 
en  el  mas  competitivo  a  nivel  económico.  Las  capacidades  gráficas  están  a  la  par  de  las  de 
Unreal  Engine  4.  Las  plataformas  de  destino  son  PC,  Playstation  4  y  Xbox  One.  Además, 
dispone  de  herramientas  que  facilitan  mucho  el  diseño  de  niveles. 

Sin  embargo,  a  diferencia  de  los  dos  motores  mencionados,  el  desarrollador  se  ve  obligado 
a  dominar  Lúa  para  escribir  la  Inteligencia  Artificial  (lA)  y  C-t-i-  para  todo  lo  demás,  lo  que 
hace  que  la  curva  de  aprendizaje  sea  mas  acentuada. 

En  esta  sección  se  ha  dado  una  visión  general  de  las  diferentes  alternativas  en  cuanto 
a  motores  de  juegos  comerciales.  En  las  siguientes  se  dará  hablará  acerca  de  las  distintas 
alternativas  de  software  libre  existentes  actualmente. 


o 

https  ://www.  unrealengine.  com/faq 
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3.2  Alternativas  libres 

El  mayor  inconveniente  de  usar  teenologías  privativas,  de  eara  a  realizar  proyeeto  orienta¬ 
do  a  un  ámbito  doeente,  son  al  menos  dos: 

■  Por  un  lado,  se  depende  eompletamente  de  una  lieeneia  de  uso  temporal.  Aunque  es 
eierto  que  existen  lieeneias  gratuitas,  ofreeen  versiones  de  los  motores  eon  una  funeio- 
nalidad  limitada  de  los  motores.  Siempre  existe  la  posibilidad  por  parte  de  la  empresa 
de  eambiar  las  eondieiones  de  uso,  lo  que  obligaría  a  eambiar  de  forma  no  trivial  el 
desarrollo  de  este  proyeeto. 

■  Las  teenologías  privativas  no  dan  aeeeso  al  eódigo  fuente.  El  estudio  del  eódigo  fuente 
es  algo  eseneial  a  la  hora  de  poder  entender  el  funeionamiento  de  un  determinado 
sistema  informátieo,  y  por  extensión,  de  un  videojuego.  Aunque  es  eierto  que  de  los 
motores  anteriormente  listados,  Unreal  da  aeeeso  al  eódigo,  no  da  eompleta  libertad  a 
la  hora  de  compartir  libremente  modifieaciones  o  fragmentos  de  eódigo.  Poder  trabajar 
libremente  eon  el  eódigo  fuente  es  la  baza  fundamental  eon  la  que  jugará  este  proyeeto 
a  la  hora  de  servir  eomo  apoyo  a  la  doeeneia,  de  modo  que  no  se  puede  renuneiar  a 
esta  earaeterístiea. 

Por  estas  razones  se  deeide  utilizar  herramientas  libres  para  desarrollar  este  proyeeto. 

3.2.1  Motor  de  Juegos  Libre:  Godot 

En  esta  seeeión  se  hablará  brevemente  de  uno  de  poeos  motores  de  juegos  3D  que  se 
distribuyen  bajo  una  lieeneia  libre:  Godot. 

Godot  Engine  es  un  motor  de  juegos  oreado  por  OKAM  Studio,  ouyo  eódigo  fuente  fue 
liberado  en  Lebrero  de  2014,  distribuido  eon  lieeneia  MIT.  Entre  las  earaeterístiea  mas  im¬ 
portantes  tenemos: 

■  Entorno  gráfioo  de  desarrollo:  Ofreeen  un  entorno  gráfioo  que  permite  orear  animaoio- 
nes,  eseenarios  y  sirve  eomo  IDE  de  programaeión. 

■  Multiplataforma:  permite  desarrollar  juegos  para  Plataformas  móviles(IOS  y  Android), 
Escritorio(Windows,  OSX  y  GNU/Linux),  Plataformas  Web  (PNaCL),  videooonsolas 
(PlayStationS  y  Playstation  Vita,  solo  para  aquellos  desarrolladores  eon  lieeneia  de 
Sony) 

■  Soporte  para  gráfioos  2D:  motor  dedieado  para  gráfioos  2D  (no  falsea  gráfioos  2D  en  un 
espaeio  3D).  Trabaja  en  eoordenadas  de  píxeles  pero  se  adapta  a  eualquier  resoluoión 
de  pantalla.  Soporta  sprites  eon  animaeiones,  polígonos,  Parallax,  oapas,  sistema  de 
partíoulas,  fisioas  en  espaeio  2D  y  deteeeión  de  eolisiones,  eteétera 

■  Soporte  para  gráfieos  3D:  soporta  modelos  3D  de  Max,  Maya,  Blender,  eon  animacio¬ 
nes  basadas  en  huesos  y  deformaeiones  de  esqueletos  y  blend  shapes.  Soporta  distintos 
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tipos  de  luces,  con  sombras  basadas  en  mascaras(5tóncí7  Shadows),  level  of  detail,  oc- 
clusion  culling,  etcétera 

■  El  núcleo  está  programado  en  C++. 

■  Tiene  un  lenguaje  de  script  propio,  llamado  GDScript,  cuya  sintaxis  es  parecida  a 
la  de  Python,  que  abstrae  al  programador  de  aspectos  de  bajo  nivel  como  gestión  de 
memoria,  la  definición  de  las  variables  se  hace  de  tal  forma  que  no  es  necesario  conocer 
el  tipo  de  datos,  etcétera. 

■  Motor  de  físicas  2D  y  3D,  con  diferentes  tipos  de  formas  de  colisión,  cuerpos  cinemá¬ 
ticos  2D  y  3D,  simulación  de  vehículos,  etcétera. 
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Godot  Engirw  vi  .0.3917-beta1  (c)  2008-2014  Juan  Linietsky,  Ariel  Marttur. 


Figura  3.1:  Interfaz  gráfica  de  Godot  Engine  ^ 


El  proyecto  está  creciendo  a  un  ritmo  muy  rápido,  teniendo  en  cuenta  que  se  liberó  en 
febrero  del  2014  y  publicó  la  primera  versión  estable  en  Diciembre  de  ese  año.  Sin  embargo, 
todavía  no  tiene  una  comunidad  bien  afianzada  y  la  cantidad  de  juegos  que  se  han  desarro¬ 
llado  con  este  motor  es  baja.  Por  esta  razón,  es  posible  que  sea  necearlo,  dependiendo  de  las 
necesidades  de  cada  des  arrollador,  llegar  a  crear  un  motor  de  juegos  propio.  En  las  siguientes 
secciones  se  dará  una  visión  general  de  dos  bibliotecas  de  software  libre  que  ayudaran  a  este 
propósito. 


3.2.2  Ogre3D 

Ogre3D  (Object-Oriented  Graphic  Engine)  [ogr]  es  un  motor  de  renderizado  de  propósito 
general  creado  por  Steve  Streeting  (también  conocido  como  Sinbad)  distribuido  bajo  licencia 
EGPE  [repb].  Fue  creado  en  2001  [ent]  con  el  propósito  de  crear  un  componente  de  rende- 
rizado  en  tiempo  real  sin  hacer  asunciones  a  nivel  de  aplicación.  El  objetivo  era  crear  un 

^  http :  //i .  imgur.  com/12z  wuj  W.  png 
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componente  genérieo  que  pudiese  ser  ampliado  a  través  de  plugins.  Desde  un  prineipio  el 
proyeeto  se  diseñó  teniendo  en  euenta  la  mantenibilidad  y  la  faeilidad  de  ampliaeión. 

OgreSD  no  fue  eoneebido  eomo  un  motor  de  juegos.  Se  pretendía  eubrir  el  mayor  espeetro 
posible,  de  manera  que  no  sólo  sirviese  a  eampos  eomo  el  de  los  videojuegos,  sino  también  a 
los  de  simulaeión,  realidad  aumentada,  realidad  virtual,. ..y  en  general,  eualquier  eampo  que 
requiriese  del  uso  de  herramientas  de  renderizado  en  tiempo  real. 

Además,  el  heeho  de  que  se  distribuya  bajo  una  lieeneia  de  eódigo  libre  eontribuye  mu- 
ehísimo  más  a  su  éxito.  Esto  es  así  debido  a  que  la  eomunidad  está  muy  involuerada  eon 
el  proyeeto,  eosa  que  podemos  observar  en  el  foro  ofieial  del  proyeeto,  donde  se  resuelven 
dudas  de  desarrollo,  se  diseute  el  roadmap,  ete.  En  euanto  a  las  eontribueiones  [pol],  los 
usuarios  de  la  eomunidad  pueden  eolaborar  bien  realizando  pull-request  al  repositorio  ofi- 
eial  [repb]  eon  sus  parehes  o  bien  reportando  bugs  al  gestor  de  ineideneias  del  proyeeto. 
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Eigura  3.2:  Esquema  general  de  la  arquiteetura  de  OgreSD"^ 

Como  se  ha  dieho  antes,  OgreSD  no  es  un  motor  de  juego.  Esto  impliea  que  será  el  desarro¬ 
llador  quien  tenga  que  eneargarse  de  aspeetos  eomo  la  gestión  de  eventos  de  entrada  (teelado, 
ratón,...),  físieas,  networking,  interfaees,  ete.  En  el  easo  del  desarrollo  de  interfaees  existen 
maneras  de  erearlas  eon  Ogre  a  través  del  uso  de  overlays;  sin  embargo,  esta  aproximaeión 
no  es  lo  sufieientemente  flexible  eomo  para  orear  interfaees  avanzadas.  Eas  oaraoterístioas 
prineipales  de  Ogre  son  [JunOó]: 

■  Mutiplataforma:  permite  el  desarrollo  para  sistemas  Windows,  GNU/Einux  y  Mae 
OS  X. 

■  Diseño  a  alto  nivel:  OgreSD  enoapsula  llamadas  a  las  librerías  gráfioas  DireetX  y 
OpenGE.  Además,  haoe  uso  de  patrones  de  diseño:  observer  para  informar  de  eventos 
y  eambios  de  estado,  singleton  para  evitar  que  exista  mas  de  una  instaneia  de  eualquier 

^http  ://www.  ogreSd .  org/tikiwiki/img/wiki_up/Root_managers .  png 
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manager,  visitar  para  realizar  operaciones  sobre  un  objeto  y  evitar  modificarlo  (por 
ejemplo,  en  los  nodos  del  grafo  de  escena),  fagade  para  unificar  el  acceso  a  operacio¬ 
nes, para  creación  de  objetos  concretos  de  interfaces  abstractas,  etc. 

■  Grafo  de  escena:  una  de  las  características  mas  importantes  del  grafo  de  escena  de 
Ogre  es  que  desacopla  el  propio  grafo  del  contenido  de  la  escena,  definiendo  una  arqui¬ 
tectura  de  pugins.  A  diferencia  de  otros  motores  gráficos,  como  Cry Engine,  UnitySD 
o  Unreal,  Ogre  no  se  basa  en  la  herencia  como  principio  de  diseño  del  grafo,  sino  en 
la  composición.  Esto  permite  expandir  el  diseño  para  soportar  otros  tipos  de  datos,  co¬ 
mo  audio  o  elementos  de  simulación  física.  En  la  Eigura  3.2  se  puede  ver  el  esquema 
general  del  grafo  de  escena  de  Ogre. 

■  Aceleración  Hardware:  Ogre  permite  definir  el  comportamiento  de  la  parte  progra- 
mable  de  la  GPU  mediante  la  definición  de  Shaders,  estando  al  mismo  nivel  de  otros 
motores  como  Unreal  o  CryEngine. 

■  Materiales:  se  definen  mediante  un  sistema  de  Scripts  y  permiten  asignar  o  cambiar 
los  materiales  de  los  elementos  de  la  escena  sin  modificar  el  código  fuente. 

■  Animación:  tres  tipos  (skeletal,  morph  y  pose).  Ea  animación  y  la  geometría  asociada 
a  los  modelos  se  almacena  en  un  único  formato  binario  optimizado.  El  proceso  mas 
empleado  se  basa  en  la  exportación  desde  la  aplicación  de  modelado  y  animación  3D 
a  un  formato  XML  (Ogre  XML)  para  convertirlo  posteriormente  al  formato  binario 
optimizado  mediante  la  herramienta  de  línea  de  órdenes  OgreXMEConverter. 

■  Composición  y  Postprocesado. 

■  Plugins:  Ogre  permite  expandir  su  funcionalidad  base  mediante  el  uso  de  plugins. 
Esto  lo  hace  tremendamente  flexible  ya  que  cuenta  con  multitud  de  plugins  para  aña¬ 
dir  efectos  de  partículas,  diferentes  tipos  de  grafos  de  escena,  efectos  de  renderizado, 
etcétera. 

■  Gestión  de  Recursos:  Ogre  ofrece  una  serie  de  gestores  de  recursos,  organizados  je¬ 
rárquicamente  por  grupos. 

■  Características  específicas  avanzadas:  El  motor  soporta  gran  cantidad  de  caracterís¬ 
ticas  de  visualización  avanzadas,  tales  como  sombras  dinámicas  (basadas  en  diversas 
técnicas  de  cálculo),  sistemas  de  partículas,  animación  basada  en  esqueletos  y  de  vér¬ 
tices,  y  un  largo  etcétera.  Ogre  soporta  además  el  uso  de  otras  bibliotecas  auxiliares 
mediante  plugins  y  conectores.  Entre  los  más  utilizados  cabe  destacar  el  soporte  del 
metaformato  Collada  o  la  reproducción  de  streaming  de  vídeo  con  Theora. 

El  motor  de  renderizado  es  uno  de  los  componentes  mas  importantes  dentro  de  un  motor  de 
juegos.  Sin  embargo,  es  necesario  dar  un  comportamiento  realista  a  los  cuerpos  gráficos  que 
se  renderizan  para  aportar  realismos  y  añadir  jugabilidad  al  mismo.  Por  tanto,  en  la  siguiente 
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sección  se  va  a  dar  una  visión  general  de  Bullet  Physics,  uno  de  los  motores  de  físicas  de 
software  libre  mas  potentes  de  la  actualidad. 

3.2.3  Bullet  Physics 

Bullet  Physics  [bule]  es  una  biblioteca  de  físicas  y  detección  de  colisiones.  Se  distribuye 
bajo  licencia  ZLib  y  está  desarrollada  usando  el  lenguaje  de  programación  C++.  El  código 
fuente  se  encuentra  disponible  en  el  repositorio  oficial  del  proyecto  [bulb].  Ofrece  soporte 
para  una  gran  multitud  de  plataformas,  tales  como  Playstation  3  y  4,  Xbox  360  y  One,  Wii, 
GNU/Linux,  Windows,  MacOSX,  iPhone,  Android  y  navegador  web  (Chrome). 

Bullet  ha  sido  usado  en  multitud  de  películas,  tales  como  Hancock  o  Sherlock  Holmes, 
así  como  videojuegos  comerciales  entre  los  que  destacan  Grand  Theft  auto  IV,  Grand  Theft 
auto  V  o  Red  Dead  Redemption.  Además,  la  National  Aeronautics  and  Space  Administra- 
tion  (NASA)  está  utilizando  Bullet  [bula]  en  un  framework  propio  de  cálculo  de  integridad 
tensional  en  robots^. 

La  principal  tarea  de  un  motor  de  físicas  es  la  de  detectar  colisiones  entre  cuerpos  físicos, 
además  de  aplicar  transformaciones  geometrías  y  restricciones  físicas  a  estos.  En  cualquier 
videojuego  se  hace  necesario  el  uso  de  un  motor  de  físicas,  por  una  serie  de  razones: 

■  Si  no  se  controlan  las  colisiones  entre  los  cuerpos,  estos  se  atravesarían  entre  sí,  res¬ 
tando  realismo. 

■  Parte  de  la  mecánica  de  juego  puede  consistir  en  hacer  chocar  unos  objetos  con  otros. 
Por  enumerar  algún  juego  de  estas  características  tenemos  Arkanoid,  donde  la  pelota 
debe  chocar  contra  los  ladrillos  o  Bubble  Bobble,  donde  el  dragón  protagonista  suelta 
burbujas  con  las  que  derrota  a  los  enemigos. 

■  Puede  ser  necesario  modelar  propiedades  físicas;  por  ejemplo,  en  juegos  de  carreras 
de  coches,  a  la  hora  de  realizar  derrapes,  es  necesario  simular  la  pérdida  de  fricción 
que  sufren  los  neumáticos. 

Gracias  al  uso  de  una  biblioteca  de  físicas  es  posible  crear  juegos  mas  realistas,  al  tiem¬ 
po  que  abstrae  al  desarrollador  de  los  detalles  de  bajo  nivel.  Entre  las  características  mas 
importantes  de  Bullet  podemos  enumerar: 

■  Detección  de  colisiones,  tanto  continua  como  discreta,  incluyendo  rayqueries  y  tests 
de  colisión  de  formas  convexas  (sweep  test).  Los  test  de  colisión  permiten  mallas  con¬ 
vexas  y  cóncavas,  además  de  todo  tipo  de  formas  primitivas. 

■  Implementa  dinámica  de  cuerpos  rígidos,  de  vehículos,  controladores  de  personajes, 
restricción  de  giro  para  ragdolls,  restricciones  de  tipo  slider,  bisagra  y  Six  Degrees  Of 
Ereedom  (6DOF). 

^del  inglés  tensegrity 
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■  Incluye  dinámica  de  cuerpos  fluidos  para  ropa,  tela  y  volúmenes  deformables  con  dos 
formas  de  interacción  con  cuerpos  rígidos,  incluyendo  soporte  de  restricciones. 

■  Existen  plugins  para  dar  soporte  a  Maya,  está  integrado  con  Blender  además  de  sopor¬ 
tar  ficheros  COLLADA. 

Arquitectura 

Bullet  ha  sido  diseñado  para  ser  modular  y  adaptable.  La  biblioteca  da  la  libertad  al  desa¬ 
rrollador  de  usar  los  componentes  que  necesite  en  cada  momento,  ignorando  los  demás.  Por 
ejemplo,  se  podría  hacer  uso  de  la  capa  de  detección  de  colisiones  sin  hacer  uso  de  las  capas 
superiores  o  viceversa,  hacer  uso  de  la  capa  de  dinámica  de  cuerpos  rígidos  ignorando  las 
capas  inferiores.  En  la  figura  3.3  se  puede  observar  un  esquema  general  de  la  organización 
por  capas  de  la  biblioteca. 


Soft  Body 
Dynamics 

Bultet 

Muid  Threaded 

Extras: 
Maya  Plugin 
hkxZdae 
.bsp,  obj. 
other  tools 

Rigíd  Body 

IDynamícs 

Collísion 

Detecbon 

Linear  Math 

Memory.  Containers 

Ligura  3.3:  Organización  por  capas  de  Bullet^ 


Encauzamiento  del  componente  de  física  de  cuerpos  rígidos 

El  siguiente  diagrama  muestra  las  estructuras  de  datos  mas  importantes,  así  como  las  eta¬ 
pas  del  encauzamiento  dentro  de  Bullet.  Este  encauzamiento  se  ejecuta  de  izquierda  a  de¬ 
recha,  comenzando  por  aplicar  la  gravedad  y  terminando  por  integrar  las  posiciones  de  los 
cuerpos. 

El  encauzamiento  y  las  estructuras  de  datos  están  representados  en  Bullet  a  través  de  la 
clase  DynamicsWorld.  Cuando  se  ejecuta  el  método  stepSimulation( )  de  dicha  clase,  en 
realidad  se  está  ejecutando  el  encauzamiento  anterior.  La  implementación  por  defecto  se 
encuentra  en  la  clase  btDiscreteDynamicsWorld. 

Bullet  permite  al  desarrollador  trabajar  con  subfases  del  encauzamiento,  como  la  de  de¬ 
tección  de  colisiones,  la  fase  en  la  que  se  aplican  los  efectos  de  las  colisiones  a  los  cuerpos 

®ManualBulletPhysics  :  https  ://goo .  gl/i4\/5n6 

^ManualBulletPhysics  :  https  ://goo .  gl/i4\/5n6 
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Figura  3.4:  Pipeline  del  componente  de  cuerpos^ 


físicos  (narrowphase)  o  la  fase  de  resolución  de  restricciones. 

3.3  Físicas  en  dinámica  de  vehículos 

En  la  sección  se  ha  hablado  de  uno  de  los  motores  de  físicas  de  software  libre  mas  potentes 
que  existen  actualmente.  En  esta  se  realizará  un  estudio  mas  concreto  acerca  de  las  fuerzas 
físicas  que  influyen  en  el  movimiento  de  un  coche. 

A  grandes  rasgos,  el  movimiento  de  un  coche  radica  en  un  conjunto  de  fuerzas  que  se 
aplican  sobre  las  ruedas  y  el  chasis  del  vehículo.  En  la  dirección  del  movimiento  del  co¬ 
che  se  aplica  una  fuerza  longitudinal,  compuesta  por  la  fuerza  que  aplican  las  ruedas,  la 
fuerza  de  frenado,  la  resistencia  que  oponen  los  neumáticos  y  la  resistencia  del  aire.  Por 
otro  lado,  en  giros  existen  fuerzas  laterales  causadas  por  la  fricción  lateral  de  las  ruedas, 
además  del  momento  angular  del  coche  y  el  esfuerzo  de  torsión  causado  por  las  fuerzas 
laterales  [Mon03] 

3.3.1  Movimientos  rectilíneos 

Ea  primera  fuerza  que  entra  en  juego  es  la  fuerza  de  tracción.  Ea  fuerza  de  tracción  es 
ocasionada  por  la  fricción  del  neumático  contra  la  superficie  del  asfalto,  que  es  provocada 
por  el  desplazamiento  del  neumático  contra  el  asfalto  debido  al  par  motor  aplicado  por  el 
motor. 

El  par  motor  es  el  momento  de  fuerza  que  ejerce  el  motor  del  coche  sobre  el  eje  de  trans¬ 
misión,  expresado  en  N.m.  El  par  motor  que  puede  entregar  depende  de  la  velocidad  a  la 
cuál  este  gira,  típicamente  expresada  en  rpm.  Ea  relación  momento  torsor/rpm  no  es  lineal, 
pero  se  representa  normalmente  como  una  curva  llamada  función  del  momento  torsor  En 
la  figura  3.5  vemos  la  curva  relativa  al  motor  del  Corvette  ESI  (5.7  litros  V8). 

El  eje  de  abscisas  está  expresado  en  revoluciones  por  minuto  (rpm)  y  el  de  ordenadas 

*La  curva  exacta  de  cada  motor  viene  determinada  por  los  test  que  los  fabricantes  los  someten 
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Figura  3.5:  Curva  de  par  motor/potencia  del  Corvette  LSI  [Mon03] 


en  Caballos  de  poteneia.  La  eurva  anterior  sólo  esta  definida  en  el  rango  de  rpm  en  el  que 
trabaja  el  motor,  el  intervalo  entre  las  1000  y  las  6000  rpm.  La  eurva  de  par  motor  representa 
la  máxima  poteneia  que  puede  entregar  el  motor  para  unas  rpm  dadas. 

El  par  motor  se  transmite  a  través  de  los  engranajes  hasta  llegar  a  las  ruedas,  que  se  acaba 
conviertiendo  en  una  fuerza  a  través  del  giro  de  estas  sobre  la  carretera,  dividido  por  el  radio. 
La  imagen  3.6  ilustra  el  proceso. 


gear 


Figura  3.6:  Par  motor  aplicado  sobre  el  eje  de  tracción  [Mon03] 

La  fuerza  de  conducción  es  la  fuerza  longitudinal  que  ejercen  las  ruedas  del  eje  de  trac¬ 
ción  sobre  la  carretera;es  decir,  la  que  hace  avanzar  al  coche.  Si  esta  fuera  la  única  fuerza 
que  influye  en  el  movimiento,  el  coche  aceleraría  hasta  alcanzar  una  velocidad  infinita.  Aquí 
es  donde  entran  en  juego  las  resistencia.  A  altas  velocidades  la  mas  importante  es  la  re¬ 
sistencia  del  aire.  Esta  fuerza  es  muy  importante  porque  es  proporcional  al  cuadrado  de  la 
velocidad. 

Es  importante  señalar  que  el  módulo  del  vector  velocidad  es  la  velocidad  a  la  que  normal- 
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mente  se  refieren  los  videojuegos,  expresada  en  Km/h  euando  hablamos  de  vehíeulos. 

La  siguiente  resisteneia  que  se  opone  al  movimiento  del  eoehe  es  la  resisteneia  al  giro  del 
neumátieo.  Es  eausada  por  la  frieeión  entre  la  goma  y  la  superfieie  de  eontaeto  debido  al 
desplazamiento  de  las  ruedas.  A  bajas  veloeidades  la  resisteneia  al  giro  es  la  mayor  fuerza 
que  eneuentra  el  eoehe  en  oposieión  a  su  movimiento,  mientras  que  a  altas  veloeidades  es  la 
resisteneia  del  aire. 

La  fuerza  logitudinal  total  es  la  suma  de  estas  tres  fuerzas. 

3.3.2  Transferencia  de  peso 

Un  efeeto  importante  que  sufre  el  eoehe  euando  aeelera  o  frena  es  la  transfereneia  dinámi- 
ea  de  peso.  Durante  el  frenado  el  eoehe  baja  el  morro  haeia  adelante.  Durante  la  aeeleraeión, 
el  eoehe  se  inelina  haeia  atrás.  Esto  se  debe  a  que  el  eentro  de  gravedad  del  eoehe  eambia, 
de  tal  forma  que  se  produee  una  variaeión  en  la  eantidad  de  peso  que  soportan  las  ruedas, 
tanto  las  traseras  eomo  las  delanteras.  La  distribueión  de  peso  afeeta  dramátieamente  a  la 
traeeión  máxima  de  eada  rueda,  ya  que  el  límite  de  frieeión  es  proporeional  a  la  earga  en  esa 
rueda. 

Para  vehíeulos  estaeionados,  el  peso  total  del  eoehe  se  distribuye  sobre  las  ruedas  delante¬ 
ras  y  traseras  de  aeuerdo  a  la  distaneia  entre  el  eje  delantero  y  trasero  al  eentro  de  masa.  En 
la  figura  3.7  se  ejemplifiea  esto. 


Eigura  3.7:  Distribueión  del  peso  del  eoehe  sobre  las  ruedas  [Mon03] 


3.3.3  Giros 

Otro  elemento  a  tener  en  euenta  euando  se  simula  giros  de  vehíeulos  es  que  el  eomporta- 
miento  del  eoehe  es  diferente  a  bajas  y  a  altas  veloeidades.  A  bajas  (apareamiento,  manio- 
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bras),  las  ruedas  giran  mas  o  menos  en  la  dirección  en  la  que  éstas  apuntan.  Para  simular 
estos  giros  no  se  necesita  considerar  fuerzas  y  ni  masas.  En  otras  palabras,  es  un  problema 
de  cinética  no  de  dinámica. 

A  velocidades  más  altas,  puede  ocurrir  que  las  ruedas  apunten  en  una  dirección  mientras 
que  el  vehículo  se  mueva  en  otra.  En  otras  palabras,  las  ruedas  a  veces  pueden  tener  una 
velocidad  cuyo  vector  dirección  no  esté  alineada  con  la  orientación  de  la  rueda.  Por  supues¬ 
to,  esto  causa  mucha  fricción,  puesto  que  los  neumáticos  están  diseñados  para  rodar  en  la 
dirección  en  que  apuntan,  lo  que  puede  ocasionar  derrapes. 


3.4  Visión  general  de  la  Inteligencia  Artificial 

Hasta  ahora  se  ha  dado  una  visión  general  de  los  aspectos  mas  importantes  que  rigen 
el  movimiento  de  un  vehículo.  Sin  embargo,  en  todo  videojuego  es  importante  que  exista 
alguna  forma  de  que  la  máquina  compita  contra  el  jugador  humano,  de  tal  manera  que  se 
ofrezca  un  reto  adicional.  En  la  siguiente  sección  se  realizará  una  visión  general  sobre  los 
aspectos  mas  relevantes  sobre  la  inteligencia  artificial  en  desarrollo  de  videojuegos. 

Se  puede  definir  la  inteligencia  artificial  como  “el  campo  de  la  ciencia  y  la  ingeniería 
que  trata  de  dar  un  comportamiento  inteligente  a  las  máquinas”;  es  decir,  es  el  campo  de  la 
ciencia  que  trata  de  que  las  máquinas  resuelvan  problemas. 

Ea  inteligencia  artificial  es  un  componente  imprescindible  en  todo  videojuego,  ya  que  da 
la  posibilidad  de  ofrecer  nuevos  retos  a  los  jugadores.  Uno  de  los  primeros  videojuegos,  Pong 
(ver  figura  3.8),  disponía  de  un  modo  de  inteligencia  artificial  que  permitía  al  jugador  humano 
competir  contra  la  máquina.  En  este  modo,  la  máquina  intentaba  predecir  el  movimiento  de 
la  pelota  en  base  a  una  serie  de  factores,  como  la  trayectoria  de  la  bola,  su  velocidad,  etcétera. 
Para  poder  ofrecer  un  reto  al  jugador,  uno  de  cada  8  frames  no  se  ejecutaba  este  algoritmo, 
de  forma  que  se  hacía  que  se  fuese  acumulando  un  error  que  diese  alguna  oportunidad  al 
jugador  humano  de  ganar. 

En  el  campo  de  los  videojuegos,  la  lA  no  comparte  los  mismos  objetivos  que  en  el  ám¬ 
bito  académico.  Ea  lA  utilizada  en  videojuegos  no  deja  de  ser  una  serie  de  heurísticas  que 
persiguen  mejorar  la  experiencia  del  jugador.  No  se  intenta  que  la  lA  de  un  videojuego  sea 
óptima,  ya  que  eso  haría  que  el  jugador  humano  tuviese  muy  pocas  posibilidades  de  ganar,  o 
en  caso  de  estar  en  igualdad  de  condiciones,  la  experiencia  sería  muy  frustrante. 

Según  Georgios  N.  Yannakakis  [Yanl2],  existen  una  serie  de  áreas  donde  las  investigacio¬ 
nes  académicas  en  lA  se  pueden  aplicar  en  el  desarrollo  de  videojuegos: 

■  Modelado  de  la  experiencia  del  jugador:  en  este  campo  se  busca  descubrir  cuál  es  la 
habilidad  y  el  estado  emocional  del  jugador,  con  el  fin  de  adaptar  el  juego.  Se  puede 
aplicar  para  balancear  dinámicamente  la  dificultad  del  juego,  con  algoritmos  como 

^https  ://upload .wikimedia . org/wikipedia/commons/f/f8/Pong . png 
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Figura  3.8:  Imagen  del  juego  Pong'^ 

Rubber  Band  (ver  3.4.2.  En  juegos  que  hagan  uso  de  una  cámara  se  puede  aplicar  para 
deducir  el  carácter  del  jugador  mediante  reconocimiento  facial^®. 

■  Generación  de  contenido  procedural:  creación  de  elementos  del  entorno  del  juego  tal 
como  escenarios,  música  e  incluso  historias  interactivas.  Por  ejemplo,  el  videojuego 
Minecraft  utiliza  el  algoritmo  Perlin  Noise^^  con  interpolación  lineal^^.  Para  la  gene¬ 
ración  de  biomas  utiliza  el  diagrama  de  Whittaker^^ .  Por  otra  parte,  en  [MdSBll]  se 
propone  un  método  de  generación  procedural  de  escenarios  utilizando  un  algoritmo 
genético. 

■  Minería  de  datos  en  los  hábitos  de  los  jugadores:  Esto  permite  a  los  diseñadores  de 
juegos  descubrir  la  forma  en  la  que  los  jugadores  usan  el  juego,  en  qué  zonas  pasan 
mas  tiempo,  y  porqué  dejan  de  jugar.  Con  este  tipo  de  conocimiento  se  puede  mejorar 
la  forma  en  que  se  monetiza  el  contenido  del  videojuego.  En  el  juego  Subnautica  se  usa 
un  sistema  de  feedback  en  el  que  los  jugadores  pueden  enviar  capturas  de  pantalla  de 
las  zonas  del  juego  que  les  gusta  y  que  no  les  gusta.  Después  los  desarrolladores  usan 
esa  y  otra  información  (como  tiempo  de  juego,  número  de  jugadores,  etcetera)  para 
tener  poder  sacar  conclusiones  acerca  del  nivel  de  satisfacción  de  sus  jugadores 

Por  otra  parte,  en  el  género  de  carreras  de  coches,  se  utilizan  una  gran  diversidad  de  al¬ 
goritmos  para  solucionar  los  diferentes  problemas  que  existen  en  este  tipo  de  juegos;  sin 
embargo,  los  principales  algoritmos  que  se  usan  son  dos: 

■  algoritmos  de  descubrimientos  de  caminos  para  solucionar  el  problema  de  recorrer  el 

'^Ejemplo  de  reconocimiento  facial;  https://www.youtube.com/watch?v=qlgZdEWKXAI 

http  ://pcg .wikidot . com/pcg- algo rithm: perlin  -  noise 

1 2 

http  ://pcg  .wikidot .  com/pcg  -  games :  minecraft 
1 3 

http  ://notch .  tumblr .  com/post/1409584546/some-work-  on-  biomes 
^^https  ://www.  youtube .  com/watch?t=372&v=Urx7WQE6NY0 
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circuito,  siendo  el  mas  utilizado  el  A*. 

■  algoritmos  genéticos  para  generación  automática  de  contenido. 

3.4.1  Algoritmo  A* 

El  algoritmo  A*  está  ampliamente  usado  para  resolver  problemas  de  búsqueda  de  caminos. 
Es  un  algoritmo  de  tipo  búsqueda  Best  Eirst  Search  (BFS)  [RN04].  Este  algoritmo  utiliza  la 
siguiente  función  de  evaluación: /fnj  =  g(n)  +  h’(n),  donde: 

■  h’(n):  representa  el  valor  heurístico  del  nodo  a  evaluar  desde  el  actual,  n,  hasta  el  final. 

■  g(n):  es  el  coste  del  camino  desde  el  nodo  inicial  hasta  el  nodo  n. 

Debido  a  que  g(n)  informa  del  coste  del  camino  desde  el  nodo  inicial  al  nodo  n,y  h(n)  del 
coste  estimado  de  ir  hasta  el  nodo  objetivo,  se  puede  decir  que  f(n)  da  el  coste  mas  barato 
estimado  de  la  solución  a  través  del  nodo  n. 

Este  algoritmo  es  completo  y  óptimo;  es  decir,  si  existe  una  solución,  la  encontrará,  y 
además,  será  la  mejor  solución.  Pero  para  que  esto  se  cumpla,  se  debe  dar  la  siguiente  con¬ 
dición:  h(n)  debe  ser  una  heurística  admisible.  Se  dice  que  una  heurística  es  admisible  si 
nunca  sobrestima  el  coste  de  alcanzar  el  nodo  objetivo.  Ya  que  g(n)  es  el  coste  exacto  para 
alcanzar  el  nodo  n,  se  tiene  como  consecuencia  inmediata  que  \af(n)  nunca  sobrestima  el 
coste  verdadero  de  una  solución  a  través  de  n 


function  A*(comienzo,  final): 
nodos_evaluados  =  {} 

frontera  =  {comienzo}  //  nodos  a  evaluar  que  pueden  llevar  hasta  el  final 
nodos-visitados  =  {} 

g [comienzo]  =0  //  Coste  del  camino  conocido 

//  Coste  total  estimado  desde  el  punto  actual  hasta  el  final  del  camino 
f[comienzo]  :=  g[comienzo]  +  coste_estimado(comienzo,  final) 

while  frontera  no  este  vacia: 

actual  =  nodo_coste_minimo(f rentera) 
if  actual  =  final 

return  reconstruir_camino(nodos_visitados,  final) 

frontera. remove(actual) 
nodos_evaluados .add (actual) 
for_each  vecino  in  nodos_vecinos(current) : 
if  vecino  in  nodos_evaluados 

continué 

g_estimado  =  g[actual]  +  distancia(actual,  vecino) 

if  vecino  not  in  frontera  or  g_estimado  <  g[vecino]: 
nodos_visitados [vecino]  =  actual 
g[vecino]  =  g_estimado 

f[vecino]  =  g[vecino]  +  coste_estimado(vecino,  final) 
if  vecino  not  in  frontera 
frontera . add (vecino) 
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return  fallo 


function  reconstruir_camino{nodos_visitados,  actual): 
camino  :=  [actual] 
while  actual  in  nodos_visitados : 

actual  =  nodos_visitados [actual] 
camino . a ppend (actual ) 
return  camino 


Listado  3.1:  Pseudocódigo  del  algoritmo  A* 

Dependiendo  de  las  partieularidades  del  problema  en  euestión,  cada  autor  realiza  diversas 
modificaciones  al  algoritmo.  Por  ejemplo,  en  [yYBL12]  se  propone  una  modificación  al 
algoritmo  A*  para  un  juego  de  carreras  en  2D,  consistente  en  dos  pasos: 

■  reducir  el  número  de  vecinos  que  se  estudian  en  cada  paso  del  algoritmo 

■  y  añadir  un  sistema  de  detección  de  colisiones  basado  en  un  código  de  color,  que  le 
permite  detectar  obstáculos  de  forma  dinámica.  En  la  figura  3.10  se  ejemplifica  esta 
técnica. 

El  primer  paso  consiste  en  reducir  el  coste  computacional  del  algoritmo  reduciendo  el 
número  de  vecinos  que  se  estudian  en  cada  paso  de  la  ejecución  del  mismo.  Debido  a  que 
la  forma  en  que  se  mueve  un  vehículo  es  en  línea  recta,  y  que  no  puede  moverse  de  forma 
lateral,  no  tiene  sentido  estudiar  los  nodos  laterales.  En  el  caso  de  los  nodos  traseros,  se 
aplica  la  misma  optimización  cuando  el  vehículo  se  mueva  marcha  atrás. 

En  cuanto  al  sistema  de  detección  de  colisiones,  esto  permite  que  los  vehículos  puedan 
adaptarse  a  los  cambios  que  se  producen  en  el  circuito  durante  el  transcurso  de  la  carrera; 
por  ejemplo,  coches  cruzados  en  mitad  del  mismo. 

lÍÍÍÍ ÍÍ1 lÍÍÍÍÍÍI 

Eigura  3.9:  Estudio  de  los  vecinos  en  el  algoritmo  A*.  A  la  izquierda  se  ve  el  caso  en  el 
algoritmo  original.  A  la  derecha,  la  propuesta  ofrecida  por  [yYBE12]  en  la  que  únicamente 
se  estudian  los  tres  vecinos  enfrente  del  nodo  actual 

Como  se  ha  visto,  el  algoritmo  A*  ofrece  una  forma  de  encontrar  un  camino  estático 
óptimo.  Esto  supone  que  la  lA  de  la  máquina  recorrerá  el  mejor  camino,  poniéndole  las 
cosas  muy  complicadas  al  jugador  humano.  De  hecho,  únicamente  si  el  jugador  hiciese  el 
mismo  recorrido  a  lo  largo  del  circuito  tendría  alguna  posibilidad  de  jugar.  Para  evitar  que  el 
juego  se  convierta  en  una  experiencia  frustrante,  existen  una  serie  de  técnicas  que  permiten 
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reducir  la  optimalidad  de  los  algoritmos,  en  pos  de  la  diversión  del  jugador. 


Figura  3.10:  Sistema  de  detección  de  colisiones  basado  en  un  código  de  color  propuesto 
por  [yYBL12] 

3.4.2  Rubber  Band 

Este  algoritmo  es  muy  usado  para  adaptar  la  dificultad  de  la  máquina  a  la  habilidad  del 
jugador.  Es  muy  usado  en  títulos  de  carreras,  entre  los  que  destacan  Needfor  speed  y  Mario 
Kart:  Double  Dashü,  para  el  cuál  nintendo  registró  una  patente  de  dicho  algoritmo  [OS07], 
en  la  que  describía  el  funcionamiento  del  mismo.  El  primer  título  que  hizo  uso  de  este  algo¬ 
ritmo  fue  Final  Lap. 

A  grandes  rasgos,  este  algoritmo  esta  diseñado  para  intentar  que  el  jugador  siempre  tenga 
algún  contrincante  de  la  máquina  cerca,  independientemente  de  su  habilidad.  Si  el  jugador 
es  muy  habilidoso,  la  máquina  aumentará  su  dificultad  de  forma  dinámica,  lo  que  hará  que 
el  jugador  tenga  dificultades  para  ganar.  Si  el  jugador  lo  es  menos,  la  máquina  bajará  su 
dificultad.  Esto  mismo  es  la  razón  por  la  cuál  cada  vez  se  utiliza  menos  este  algoritmo. 
Debido  a  la  dificultad  de  adaptarse  al  comportamiento  del  jugador,  generalmente  ocurre  una 
de  las  dos  situaciones  siguientes: 

■  la  máquina  adquiere  un  nivel  de  dificultad  demasiado  elevado  para  el  jugador,  de  forma 
que  lo  que  en  principio  parecía  una  victoria  fácil  acaba  siendo  una  milagrosa  victoria 
por  parte  de  la  máquina,  que  de  pronto  es  mas  rápida,  mas  hábil  y  mejor  en  todos  los 
aspectos  que  el  jugador. 

■  la  máquina  baja  el  nivel  de  dificultad  para  adaptarse  al  jugador  humano,  lo  que  resulta 
en  una  victoria  sencilla  debido  a  que  la  máquina  baja  demasiado  el  nivel  de  dificultad 
y  tras  esto  no  reajusta  suficientemente  rápido  el  nivel. 
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3.5  Caso  de  estudio:  The  Open  Racing  Car  Simulator  (TORCS) 

TORCS  [HS13]  es  un  simulador  de  carreras  multiplataforma  desarrollado  inicialmente  por 
Eric  Espié  y  Christophe  Guionneau  y  ampliado  sustancialmente  por  parte  de  la  comunidad. 
Permite  jugar  contra  oponentes  simulados  por  la  máquina,  así  como  se  da  la  opción  a  la  co¬ 
munidad  de  implementar  sus  propios  agentes  inteligentes,  que  sustituyan  a  la  lA  por  defecto 
o  incluso  al  jugador  humano. 


Eigura  3.11:  Vista  general  de  la  arquitectura  TORCS  [OPA+09] 

Tiene  implementación  en  GNU/Linux(todas  las  arquitecturas,  32  y  64  bits,  little  y  big 
endian),  EreeBSD,  OpenSolaris,  MacOSX,  Windows  (32  y  64  Bits).  Está  escrito  en  C++,  se 
distribuye  bajo  licencia  GPL  y  el  código  fuente  está  disponible  se  puede  ver  en  el  siguiente 
repositorio  [repa].  Dispone  de  mas  de  50  modelos  de  coches  y  mas  de  20  réplicas  de  circuitos 
reales,  así  como  100  robots  distintos. 

En  TORCS  un  robot  no  es  mas  que  un  agente  capaz  de  competir  en  una  carrera  dentro 
de  un  circuito.  Es  algo  así  como  un  programa  que  controla  un  vehículo  dentro  del  juego. 
Gracias  a  la  versatilidad  que  aporta  poder  implementar  robots  propios,  se  han  llegado  a  crear 
incluso  campeonatos  en  los  que  poner  en  práctica  las  implementaciones  propias  de  agentes 
inteligentes 

Hasta  ahora,  se  ha  dicho  que  TORCS  da  la  opción  de  implementar  sus  propios  robots,  o 
agentes.  En  la  terminología  que  usa,  estos  robots  se  llaman  controladores.  Los  controladores 
son  robots  que  se  comunican  con  el  núcleo  del  juego  a  través  de  una  conexión  UDP.  En  el 
juego,  un  bot  se  encarga  de  hacer  de  intermediario  entre  el  núcleo  del  motor  del  juego  y 
este  controlador.  En  la  figura  3.1 1  se  puede  ver  la  arquitectura  de  TORCS.  Los  controladores 
reciben  datos  de  la  carrera  a  través  de  unos  sensores.  La  lista  completa  de  sensores  se  puede 

*^ver;  http://www.berniw.org/trb/ 
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ver  en  la  figura  3.1. 


Naiiie 

Raiige 

(unít) 

Descrípiion  i 

1 

angle 

$[\pi +\pi]$ 
(rad) 

Angle  between  the  car  direction  and  the  direction  of  the  track  axis. 

curLapTime 

[0,-]  (s) 

Time  elapsed  duhng  current  lap. 

damage 

[0,-]  (point) 

Current  damage  ot  the  car. 

distFromStart 

[0,-l  (m) 

Dístance  of  the  car  from  the  start  line  along  the  track  line. 

distPaced 

[0,-1  (m) 

Distance  covered  from  the  beginning  of  the  race. 

fuel 

[0,-1  (1) 

Current  fuel  level. 

gear 

Current  gear:  ?1  is  reverse,  0  is  neutral  and  the  gear  from  1  to  6. 

lastLapTíme 

[0,-l  (s) 

Time  to  complete  the  last  lap 

opponents 

[0.100]  (m) 

Vector  of  36  sensors  that  detects  the  opponent  distance  in  meters  within  a 
specific  10  degrees  sector:  each  sensor  covers  10  degrees,  from  $-\pi$  to  $\pi$ 
infront  ofthe  car. 

racePos 

1,  2,. .. 

Position  in  the  race  with  to  respect  to  other  cars. 

rpm 

[2000- 

7000] 

(rpm) 

Number  of  rotation  per  minute  of  the  car  engine. 

speedX 

?  (km/h) 

Speed  of  the  car  along  the  longitudinal  axis  of  the  car. 

speedY 

?  (km/h) 

Speed  of  the  car  along  the  transverse  axis  of  the  car. 

track 

[0,100]  (m) 

Vector  of  19  range  finder  sensors:  each  sensors  represents  the  distance 
between  the  track  edge  and  the  car.  Sensors  are  oriented  every  10  degrees 
from  $-\pi/2$  and  $+\pi/2$  .  Distance  are  in  meters.  When  the  car  is  outside  oí 
the  track,  these  valúes  are  not  reliabie! 

trac  kP  os 

? 

Distance  between  the  car  and  the  track  axis.  The  valué  is  normalized  w.r.tto  the 

track  wldth:  it  is  0  when  car  is  on  the  axis,  ?1  when  the  car  is  on  the  right  edge  of 
the  track  and  +1  when  it  is  on  the  left  edge  of  the  car.  Valúes  greater  than  1  or 

smaller  than  ?1  means  that  the  car  is  outside  of  the  track. 

wheeISpinVel 

[0,^rad/s2 

Vector  ot  4  sensors  representing  the  rotation  speed  of  wheels. 

Cuadro  3.1:  Lista  de  sensores  de  TORCS  [OPA+09] 


Una  vez  que  el  controlador  obtiene  los  valores  de  los  sensores  desde  el  servidor,  se  infe¬ 
rirán  comandos  de  salida  para  llevar  a  cabo  la  conducción  del  coche  simulado  por  medio  de 
los  actuadores  del  mismo  [OPA+09] .  Los  actuadores  representan  la  acción  que  el  bot  cliente 
puede  realizar  y,  por  lo  tanto,  cómo  puede  afectar  el  estado  de  juego  actual.  La  figura  3.2 
muestra  una  descripción  detallada  de  los  actuadores  disponibles.  Los  actuadores  acelera¬ 
ción,  freno,  efectores  engranaje  y  de  dirección  representan  algunas  acciones  de  control  en  el 
coche. 

Dejando  de  lado  el  caso  de  TORCS,  en  cualquier  videojuegos  de  carreras  uno  de  los  princi¬ 
pales  problemas  a  los  que  se  enfrenta  un  desarrollador  que  quiere  implementar  un  mecanismo 
de  inteligencia  artificial  es  el  de  búsqueda  de  caminos.  Los  coches  controlados  por  la  máqui¬ 
na  deben  ser  capaces  de  encontrar  un  camino  a  través  del  circuito  para  poder  llegar  hasta  la 
meta. 
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fJame 

Range 

Description 

accel 

[0,1] 

Virtual  gas  pedal  (0  means  no  gas,  1  full  gas). 

brake 

[0,1] 

Virtual  brake  pedal  (0  means  no  brake,  1  full  brake). 

gear 

? 

1,0,1, ...6 

Gear  valué. 

steer 

[n,i] 

Steering  valué;  ?1  and  +1  means  respectively  full  right  and  left,  that  corresponds  to  an 
angle  of  0.785398  rad. 

meta 

0,1 

This  is  meta-control  command:  0  do  nothing,  1  ask  competition  serverto  restartthe  race. 

Cuadro  3.2:  Lista  de  actuadores  de  TORCS  [OPA+09] 

3.6  Historia  de  los  juegos  en  red 

Lftilizar  la  red  para  comunicar  las  diferentes  instancias  del  juego  implica  una  limitación 
física  insalvable:  la  latencia.  Esto  es  especialmente  grave  cuando  esa  red  es  Internet,  ya 
que  involucra  computadores  que  pueden  estar  repartidos  en  cualquier  parte  del  planeta.  Eso 
significa  que  la  latencia  será  muy  diferente  entre  dos  jugadores  cualesquiera  debido  a  que  la 
calidad  y  características  concretas  de  su  conexión  a  la  red  pueden  ser  muy  diferentes. 

En  cualquier  juego  en  red,  existen  dos  propiedades  clave  relacionadas  con  la  latencia:  la 
consistencia  y  la  inmediatez  [SH06]. 

Ea  consistencia  es  un  indicador  de  las  diferencias  entre  la  percepción  que  cada  jugador 
tiene  del  mundo  del  juego  respecto  de  la  «versión  oficial».  Si  un  jugador  recibe  un  mensaje 
de  actualización  en  un  instante  diferente  a  la  de  otro  jugador,  obtendrán  una  representación 
diferente  del  entorno  durante  ese  intervalo.  De  modo  que,  a  mayor  latencia  menor  consisten¬ 
cia.  Por  ejemplo,  en  un  juego  de  carreras,  es  común  que  la  posición  dentro  del  circuito  de 
un  determinado  coche  no  corresponda  exactamente  para  el  jugador  que  lo  pilota  que  para  los 
contrincantes.  Esto  puede  tener  implicaciones  negativas  sobre  la  jugabilidad  y  puede  llevar  a 
situaciones  donde  se  violen  las  propias  reglas  del  videojuego. 

Por  otro  lado,  la  inmediatez  mide  el  tiempo  que  le  lleva  al  juego  representar  las  accio¬ 
nes  de  los  usuarios.  Por  ejemplo,  en  un  juego  Eirst  Person  Shooter  (FPS),  el  jugador  espera 
oír  inmediatamente  el  sonido  del  disparo  de  su  propia  arma.  Si  el  juego  necesita  confirmar 
que  la  acción  del  jugador  y  sus  consecuencia,  tendrá  que  esperar  una  validación  (remota) 
y,  por  tanto,  el  resultado  puede  perder  mucho  realismo.  Como  esa  comprobación  implica 
comunicación  con  otras  instancias  del  juego,  una  mayor  latencia  reduce  la  inmediatez. 

Además,  aunque  es  lo  deseable,  no  es  posible  maximizar  a  la  vez  consistencia  e  inmedia¬ 
tez.  Maximizar  la  consistencia  implica  comprobar  todas  las  acciones  y  eso  reduce  la  inme¬ 
diatez.  Al  mismo  tiempo,  aumentar  la  inmediatez  implica  crear  potenciales  inconsistencias. 
En  función  del  tipo  de  juego,  será  más  adecuado  sacrificar  una  sobre  la  otra. 

A  continuación  se  describen  las  técnicas  básicas  utilizadas  en  los  juegos  en  red  empezando 
por  las  más  simples  y  veteranas. 
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3.6.1  Peer-to-Peer  Lockstep 

Los  primeros  juegos  en  red  se  eomunicaban  usando  un  modelo  de  pares,  eon  cada  orde¬ 
nador  intercambiando  información  con  cada  uno  de  los  demás,  en  una  topología  de  red  en 
malla  completamente  conectada.  En  la  figura  3.12  se  puede  ver  un  ejemplo  de  red  Peer-to- 
Peer  (P2P).  Todavía  se  puede  ver  este  modelo  vivo  en  los  juegos  de  tipo  Real  Time  Strategy 
Games  (RTS). 


Figura  3.12:  Ejemplo  de  red  Peer  to  Peer.  Cada  ordenador  está  conectado  con  los  demás 
miembros  de  la  aplicación,  proporcionando  y  solicitando  información  a  los  demás  pares 

Ea  idea  básica  del  modelo  P2P  Lockstep  consiste  en  comenzar  la  partida  en  un  estado 
inicial  común  para  todos  los  jugadores.  Tras  esto,  cada  jugador  ejecuta  acciones  típica  del 
juego  (mover  unidades,  comprar  un  arma,  etcétera)  e  informa  de  ello  a  cada  uno  de  los  de¬ 
más  jugadores.  Al  mismo  tiempo,  todos  los  jugadores  esperan  la  recepción  de  mensajes  que 
contienen  la  información  de  las  acciones  ejecutadas  por  los  demás.  Cada  jugador  se  quedará 
esperando  la  recepción  de  los  mensajes  de  cada  uno  de  los  demás  jugadores,  no  pudiendo 
realizar  ninguna  otra  acción  hasta  la  recepción  completa  del  conjunto  de  acciones. 

Esta  solución  parece  simple  y  elegante,  pero  desafortunadamente  tiene  una  serie  de  limi¬ 
taciones. 

Primero,  es  excepcionalmente  difícil  asegurar  que  un  juego  en  red  sea  completamente 
determinista.  Por  ejemplo,  en  un  juego  Real  Time  Strategy  Games  (RTS)  una  unidad  pue¬ 
de  tomar  un  camino  ligeramente  diferente  en  dos  máquinas,  llegando  antes  a  la  batalla  en 
una  instancia  de  juego,  mientras  que  en  otra  llega  tarde.  Esta  inconsistencia  ocasiona  una 

'^https  ://upload  .wikimedia .  org/wikipedia/commons/thumb/3/3f /P2P-  network.  svg/200px-  P2P-  network.  svg . 
png 
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desincronización  que  altera  el  resultado  del  videojuego  en  cada  una  de  las  instancias. 

La  siguiente  limitación  radica  en  que  para  asegurar  la  consistencia,  es  necesario  que  cada 
jugador  espere  a  recibir  los  mensajes  que  informan  de  los  acciones  de  los  demás,  antes  de 
poder  hacer  efectivas  sus  acciones.  Es  importante  debido  a  que  se  necesita  conocer  el  estado 
de  los  demás  jugadores  para  poder  ejecutar  el  juego,  y  esta  información  se  deduce  a  partir  de 
las  acciones  de  cada  jugador.  Esto  perjudica  gravemente  a  la  inmediatez,  ya  que  las  latencias 
de  todos  los  jugadores  se  igualan  a  la  del  jugador  con  mayor  latencia.  En  determinados  vi¬ 
deojuegos,  ésta  es  una  propiedad  tan  importante  que  es  necesario  darle  prioridad  por  encima 
de  todo  lo  demás. 

Ea  última  limitación  ocurre  debido  a  la  manera  en  que  se  sincroniza  el  juego  con  este  pro¬ 
tocolo.  Para  poder  lograr  la  sincronización,  es  necesario  que  todos  los  jugadores  comiencen 
la  partida  desde  el  mismo  estado  inicial.  Esto  normalmente  se  consigue  obligando  a  los  ju¬ 
gadores  a  unirse  a  una  pantalla  de  creación  de  partida  antes  de  comenzar  a  jugar.  Debido  a 
la  dificultad  de  capturar  y  transmitir  un  estado  consistente,  normalmente  se  impide  que  los 
jugadores  se  unan  a  la  partida  una  vez  esta  ha  comenzado. 

Eas  limitaciones  de  este  modelo  se  comenzaron  a  observar  con  la  aparición  del  título 
Doom,  de  idSoftware.  Doom  disponía  de  un  modo  de  juego  multijugador,  el  cuál  fue  diseña¬ 
do  para  ser  jugado  en  LAN,  de  forma  que  cuando  se  jugaba  a  través  de  Internet,  los  problemas 
de  este  protocolo  para  adaptarse  a  condiciones  de  red  adversas^^  se  hacían  evidentes. 

3.6.2  Cliente- Servidor 

Debido  a  los  problemas  que  tenía  el  protocolo  anterior  a  la  hora  de  sincronizar  conexiones 
con  latencias  elevadas,  fue  necesario  cambiarlo  por  otro  que  ayudase  a  aumentar  la  inmedia¬ 
tez  en  los  juegos  en  red. 

En  1996,  John  Carmack  utilizó  un  modelo  de  red  diferente  para  el  título  Quake,  que  usaba 
una  arquitectura  cliente- servidor.  Dicho  modelo  se  caracteriza  por  tener  un  componente  cen¬ 
tral,  llamada  servidor,  que  responde  a  una  serie  de  peticiones  realizadas  por  otras  entidades 
llamadas  clientes.  Ea  figura  3.13  se  puede  ver  un  ejemplo  de  modelo  cliente-servidor. 

Bajo  este  modelo,  cada  jugador  ejecuta  un  que  se  comunica  sólo  con  el  servidor.  A  dife¬ 
rencia  del  modelo  anterior,  en  el  que  cada  par  ejecuta  una  instancia  del  juego,  en  este  existe 
una  única  instancia,  que  se  halla  en  el  servidor. 

De  esta  forma,  los  clientes  envían  las  acciones  que  realizan  los  jugadores  y  esperan  a  que 
el  servidor  les  mande  datos  actualizados  del  estado  del  juego.  Ea  mejora  que  supone  este 
cambio  en  el  modelo  de  red  es  que  el  tiempo  que  cada  jugador  debe  esperar  hasta  que  se 

'*en  Internet  es  común  tener  conexiones  con  latencias  altas  (>100ms),  jitter  y  elevado  porcentaje  de  pérdida 
de  paquetes 

*®https  ://upload  .wikimedia .  org/wikipedia/commons/thumb/c/c9/Client-  server-model .  svg/ 

20O0px- Client- server-model . svg . png 
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Figura  3.13:  Ejemplo  de  red  Cliente-Servidor^^ 


hagan  efeetivas  sus  aeeiones  ya  no  es  la  lateneia  del  jugador  eon  la  mayor  de  todos,  sino  que 
es  la  lateneia  que  haya  entre  su  eliente  y  el  servidor.  Eso  mejora  en  parte  la  inmediatez,  ya 
que  si  el  jugador  tiene  una  buena  eonexión  a  Internet,  los  demás  jugadores  no  van  a  degradar 
su  experieneia  de  juego. 

Por  otra  parte,  graeias  al  servidor  se  garantiza  la  consistencia  de  la  partida,  dado  que 
aetúa  eomo  entidad  autorizadora,  eomprobando  que  las  aeeiones  de  eada  eliente  son  legales 
e  informándoles  del  estado  de  la  partida  en  eada  momento. 

Sin  embargo,  aunque  eon  este  eambio  el  problema  eon  la  lateneia  se  eonsigue  paliar,  este 
sigue  siendo  un  problema  grave.  En  la  versión  original  de  Quake,  el  jugador  podía  sentir  la 
lateneia  existente  entre  su  ordenador  y  el  servidor.  Por  ejemplo,  euando  el  jugador  presionaba 
el  botón  de  avanzar,  tenía  que  esperar  el  tiempo  que  tardase  el  mensaje  en  viajar  desde  su 
ordenador  hasta  el  servidor  y  volver  eon  la  informaeión  del  servidor  para  poder  realizar 
el  movimiento;  es  deeir,  el  jugador  tenía  que  esperar  un  tiempo  igual  al  Round-Trip  delay 
Time  (RTT)  para  poder  haeer  efeetiva  eualquier  aeeión. 

Histórieamente,  este  problema  fue  resuelto  en  dos  partes.  La  primera  fue  la  implemen- 
taeión  de  meeanismos  de  predieeión  de  movimiento  en  el  lado  del  eliente,  téeniea  que  fue 
desarrollada  por  John  Carmaek  para  Quake  World  y  después  ineorporada  eomo  parte  del  mo¬ 
delo  de  red  de  Unreal  por  Tim  Sweeney  [BerOlb].  La  segunda  parte  eonsiste  en  meeanismos 
de  eompensaeión  de  la  lateneia  desarrollados  por  Yahn  Bemier,  para  el  título  CounterStrike 
de  Val  ve  [BerOla]. 


3.6.3  Mecanismo  de  predicción  en  el  lado  del  cliente 

Para  redueir  el  impaeto  de  la  lateneia  sobre  la  partida  se  hizo  neeesario  modifiear  el  eliente, 
de  forma  que  dejase  de  ser  un  terminal  tonto,  que  únieamente  envía  eomandos  al  servidor 
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y  ejecuta  los  comandos  recibido  por  éste,  para  poder  ejecutar  las  acciones  necesarias  para 
hacer  efectivas  las  acciones  del  jugador  en  el  momento  en  el  que  la  realiza.  De  esta  manera 
se  mejora  la  inmediatez  del  juego,  dándole  feedback  inmediato.  Para  que  el  cliente  pueda 
hacer  efectivas  las  acciones  de  su  jugador,  es  necesario  que  pueda  ejecutar  una  simulación 
del  mundo  del  juego. 

Con  el  método  anterior,  para  que  el  cliente  pudiese  hacer  efectiva  una  acción  del  jugador, 
debía  enviar  un  mensaje  al  servidor  informándole  de  qué  acciones  quería  ejecutar,  y  si  este  le 
daba  permiso,  podría  llevarlas  a  cabo  cuando  recibiese  la  confirmación  del  servidor.  Con  el 
mecanismo  de  predicción,  el  cliente  puede  realizar  una  acción  del  juego  (avanzar,  disparar, 
etcétera)  en  el  momento  en  el  que  el  jugador  pulsa  alguna  tecla  y  dejar  para  mas  tarde  la 
sincronización  con  los  mensajes  recibidos  del  servidor. 

Sin  embargo,  el  servidor  sigue  siendo  un  componente  autorizados  Por  tanto,  aunque  el 
cliente  pueda  ejecutar  inmediatamente  las  acciones  de  su  jugador,  sigue  estando  sometido  a 
las  decisiones  del  servidor.  Si  éste  le  informa  de  que  alguna  acción  no  es  válida  (por  ejemplo, 
porque  es  ilegal  de  acuerdo  con  las  normas  del  juego)  o  la  simulación  del  cliente  queda  desin¬ 
cronizada  con  respecto  a  la  del  servidor,  el  cliente  tendrá  que  deshacer  todas  las  acciones  que 
sea  necesario  y  volver  a  ejecutar  la  simulación  del  mundo  hasta  que  quede  sincronizada  con 
la  del  servidor. 

Aunque  la  implementación  del  cliente  se  complica  mucho  debido  a  la  sincronización  obli¬ 
gatoria  con  la  instancia  del  servidor,  existe  una  ventaja  al  hacer  esto.  Si  el  cliente  autorizara 
sus  propias  acciones  sería  trivial  modificarlo  para  hacer  trampas.  Al  obligar  al  cliente  a  pasar 
por  el  servidor  para  autorizar  sus  acciones,  se  complica  mucho  tomar  ventaja  del  juego. 

Por  otra  parte,  no  es  trivial  realizar  una  corrección  cuando  se  detecta  una  inconsistencia. 
El  cliente  debe  aceptar  la  actualización  procedente  del  servidor,  pero  debido  a  la  latencia 
entre  ellos,  esta  corrección  hará  referencia  a  un  momento  «pasado»  en  la  simulación  de  la 
partida.  Por  ejemplo,  si  el  RTT  entre  cliente  y  servidor  es  de  200  m,  cualquier  corrección  por 
parte  del  servidor  será  referente  a  un  momento  de  la  partida  200ms  en  el  pasado,  relativo  al 
tiempo  en  el  cuál  el  cliente  había  predicho  su  propio  movimiento. 

Ya  que  el  cliente  tiene  que  sincronizar  su  estado  con  el  del  servidor  (que  es  quien  ejecuta  la 
instancia  real  del  juego),  debe  ser  capaz  de  «rebobinar»  el  estado  de  su  simulación  para  que 
sea  coherente  con  las  actualizaciones  que  recibe  del  servidor.  Si  el  cliente  aplica  directamente 
la  corrección,  al  mismo  tiempo  tiene  que  poder  deshacer  por  completo  cualquier  predicción 
realizada.  Para  poder  hacer  esto,  la  solución  pasa  por  tener  un  buffer  circular  en  el  que  se 
almacenarán  los  estados  y  pulsaciones  pasadas  del  jugador,  de  modo  que  cuando  el  cliente 
recibe  una  corrección  procedente  del  servidor,  puede  descartar  cualquier  estado  posterior  al 
estado  referido  por  el  mensaje  del  servidor  y  ejecutar  el  juego  a  partir  de  ese  momento.  La 
figura  3.14 
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Figura  3.14:  Ejemplo  del  proceso  de  sincronización  entre  un  cliente  y  un  servidor 

De  esta  forma,  el  jugador  parece  controlar  su  propio  personaje  sin  ninguna  latencia  y 
siempre  que  el  código  de  simulación  del  cliente  y  del  servidor  sea  determinista. 

Sin  embargo,  de  la  explicación  anterior  se  refleja  otro  problema:  la  latencia  afecta  tanto 
al  servidor  como  al  cliente.  El  servidor  tiene  que  comprobar  si  las  acciones  del  jugador  son 
legales.  Para  ello,  debe  ejecutar  las  acciones  que  recibe  del  cliente  sobre  su  instancia  del 
juego;sin  embargo,  debido  a  que  los  mensajes  llegan  con  retardo  debido  a  la  latencia,  una 
acción  que  se  debería  ejecutar  en  el  instante  200  llega  X  ms  mas  tarde,  por  lo  que  el  servidor 
intentará  ejecutar  dicha  acción  en  el  instante(200  +  X).  En  el  momento  en  el  que  llegan  los 
mensajes  del  cliente  al  servidor,  es  demasiado  tarde  y  no  tienen  sentido  en  el  contexto  en 
el  que  se  encuentra  el  servidor.  Para  solventar  este  problema  se  utiliza  la  compensación  de 
latencia. 

3.6.4  Compensación  de  latencia 

Ea  compensación  de  latencia  es  un  método  para  normalizar  el  estado  del  servidor  cada 
vez  que  comprueba  la  validez  de  una  acción  enviada  por  un  cliente.  A  grandes  rasgos,  el 
algoritmo  es  el  siguiente  [BerOla]: 

■  Antes  de  ejecutar  un  comando  de  usuario,  el  servidor: 

•  Calcula  la  latencia  del  cliente 

•  Busca  en  el  histórico  del  cliente  la  última  actualización  enviada  antes  de  que  le 
enviara  la  acción  actual. 
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•  Comprueba  si  la  acción  es  legal. 

•  Actualiza  el  estado  de  la  partida  para  que  se  ajuste  al  instante  de  tiempo  corres¬ 
pondiente  al  paso  anterior. 

■  Ejecuta  la  acción,  actualiza  el  estado  de  la  partida  teniendo  en  cuenta  las  repercusiones 
de  la  acción  ejecutada  e  informa  a  todos  los  jugadores  de  los  cambios  producidos. 

■  Deshace  todos  los  cambios  anteriores  para  seguir  con  la  ejecución  del  juego  desde  el 
punto  en  el  que  se  quedó. 

Esta  técnica  elimina  gran  cantidad  de  inconsistencias  que  ocurrirían  por  culpa  de  la  laten- 
cia.  Por  ejemplo,  supongamos  una  situación  típica  que  ocurría  en  una  partida  de  un  juego 
FPS  si  el  servidor  no  implementase  la  técnica  de  compensación  de  latencia,  situación  que  se 
encuentra  ilustrada  en  la  figura  3.15: 

■  Enjugador  A  dispara  a  un  jugador  B.  Sin  embargo,  debido  a  las  inconsistencias  crea¬ 
das  por  la  latencia,  el  cliente  del  jugador  A  renderiza  al  personaje  del  jugador  B  en  una 
posición  incorrecta.  En  la  figura  3.15  sería  el  soldado  que  se  encuentra  atrasado. 

■  El  jugador  A  realiza  la  acción  de  disparar,  el  cliente  ejecuta  la  acción  e  informa  al 
servidor.  Debido  a  que  el  cliente  ejecuta  la  acción  en  el  momento  en  el  que  se  lo  indica 
el  jugador,  en  la  simulación  del  cliente  del  jugador  A,  el  jugador  B  ha  muerto. 

■  El  servidor  recibe  el  mensaje  del  jugador  A,  pero  como  no  realiza  compensación  de 
latencia,  la  posición  del  jugador  B  en  el  servidor(representada  por  el  soldado  adelan¬ 
tado)  y  en  cliente  del  jugador  A  difieren.  Por  tanto,  en  el  servidor  el  jugador  hierra  el 
disparo  e  informa  de  ello  al  cliente  del  jugador  A. 

■  Cuando  el  cliente  del  jugador  A  recibe  la  actualización,  éste  debe  deshacer  toda  una 
serie  de  acciones  y  corregir  su  estado  para  que  sea  consistente  con  el  del  servidor. 

En  el  ejemplo,  si  el  servidor  realizase  compensación  de  latencia,  las  posiciones  del  jugador 
B  en  el  servidor  y  en  el  cliente  del  jugador  A  diferirían  en  menor  medida;  por  tanto,  sería 
menos  probable  que  el  jugador  A  hubiese  fallado  su  disparo. 

3.7  Técnicas  de  sincronización  en  videojuegos 

Eo  mencionado  en  las  secciones  anteriores  ha  sido  un  resumen  de  la  evolución  que  han 
sufrido  los  modelos  de  red  de  los  videojuegos  a  los  largo  de  su  historia.  En  esta  sección  se 
profundizará  un  poco  mas  en  cada  técnica  enumerada  anteriormente.  Existe  poca  literatura 
que  clasifique  los  modelos  de  red  en  videojuegos,  de  forma  que  en  este  documento  se  va  a 
trabajar  con  la  clasificación  creada  por  Glenn  Fiedler. 

^^Valve-CounterStrike:https  ://developer .  valvesof  twa  re .  com/wiki/File :  Lag.compensation .  j  pg 
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Figura  3.15:  Ejemplo  de  eompensación  de  lateneia^® 

3.7.1  Lockstep  determinista 

Es  un  método  de  sineronizaeión  entre  proeesos  remotos  mediante  el  envío  de  las  aeeiones 
del  jugador,  en  lugar  de  enviar  el  estado  eompleto  de  la  simulaeión  del  juego  [FielO].  Co¬ 
menzando  en  un  estado  inicial  S{n),  se  ejecuta  la  simulación  usando  las  acciones  recibidas 
E{n)  para  generar  el  estado  S'(n-|- 1),  tras  lo  cuál  se  usan  las  acciones  E{n+1)  para  generar 
el  estado  S{n  +  2)  y  así  sucesivamente.  A  grandes  rasgos,  se  trata  de  una  especie  induc¬ 
ción  matemática  donde  se  avanza  usando  las  acciones  y  el  estado  anterior,  manteniéndolo 
sincronizado  sin  necesidad  de  enviarlo  explícitamente. 

La  principal  ventaja  de  este  modelo  de  red  es  que  el  ancho  DE  BANDA  necesario  para 
trasmitir  las  acciones  de  los  jugadores  es  independiente  del  número  de  objetos  en  la  simula¬ 
ción.  Se  puede  sincronizar  la  simulación  física  de  un  millón  de  objetos  con  el  mismo  ancho 
de  bando  necesario  para  sincronizar  uno.  Para  esto,  es  necesario  que  cada  una  de  las  instan¬ 
cias  del  juego  ejecuten  un  motor  de  físicas  completamente  determinista  que  permita  generar 
los  siguientes  estados  del  juego  a  partir  de  las  acciones  generadas  por  todos  los  jugadores  de 
la  partida. 

Un  aspecto  a  tener  en  cuenta  es  que  para  poder  generar  el  estado  S(n),  se  necesitan  las 
acciones  E(n-l)  de  todos  los  jugadores.  Esto  hace  que  sea  una  técnica  de  sincronización  apta 
para  un  modelo  Peer-to-Peer,  pero  no  tanto  para  uno  basado  en  Cliente-Servidor.  Por  esta 
razón,  este  tipo  de  técnica  es  apropiada  para  juegos  con  un  número  de  jugadores  que  oscilen 
entre  2  y  4. 

Un  punto  a  favor  de  esta  técnica  es  que  el  ancho  de  banda  consumido  es  marginal,  razón 
por  la  cuál  se  usaba  en  los  primeros  juegos  en  red,  cuando  las  conexiones  de  red  apenas 
superaban  el  KB/segundo. 
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3.7.2  Snapshots  e  Interpolación 

A  medida  que  el  número  de  jugadores  aumenta,  aumenta  la  cantidad  de  información  que 
hay  que  enviar  para  poder  sincronizar  el  juego,  y  por  tanto,  aumenta  la  dificultad  para  man¬ 
tener  una  ejecución  completamente  determinista  del  videojuego. 

La  interpolación  basada  en  snapshots  es  una  técnica  de  sincronización  completamente 
diferente  a  la  anterior.  En  lugar  de  tener  un  motor  de  físicas  ejecutándose  en  todas  y  cada  una 
de  las  instancias  del  juego,  la  sincronización  pasa  por  crear  un  snapshot  del  estado  global 
de  la  partida  e  interpolar  entre  los  diferentes  snapshot  que  se  reciben.  Se  puede  definir  un 
snapshot  como  un  resumen  del  estado  global  del  juego,  almacenado  normalmente  en  una 
estructura  de  datos  que  contiene  la  información  mas  importante  de  la  partida:  puntuación  y 
posición  en  el  mundo  de  cada  jugador,  acciones  ejecutadas  por  jugador,  etcétera. 

Típicamente,  esta  técnica  de  sincronización  tiene  sentido  cuando  se  usa  un  modelo  cliente 
servidor,  donde  el  servidor  actúa  como  un  componente  autorizador,  mientras  que  el  cliente 
no  es  mas  que  un  terminal  tonto  que  interpola  entre  los  snapshots  que  recibe  del  servidor. 
En  este  caso,  el  servidor  ejecuta  la  única  instancia  real  del  juego,  haciendo  uso  de  un  motor 
de  físicas  que  realiza  la  simulación  física  de  la  partida.  Este  servidor  periódicamente  genera 
snapshots  del  juego,  que  envía  a  cada  uno  de  los  clientes. 

Uno  de  los  puntos  fuertes  de  esta  técnica  es  que  eligiendo  una  técnica  de  interpolación 
correcta,  no  hay  peligro  de  que  la  simulación  quede  desincronizada  por  culpa  de  errores  en 
los  cálculos  en  punto  flotante  que  tienen  los  motores  de  físicas  de  un  ordenador  a  otro. 


Tipos  de  interpolación 

Ea  interpolación  es  un  método  de  análisis  numérico  para  calcular  valores  intermedios  entre 
dos  puntos.  Esta  técnica  es  ampliamente  utilizada  en  gráficos  por  computador,  ya  que  permite 
realizar  transiciones  entre  conjuntos  de  datos  dispares.  A  continuación  se  listan  algunos  de 
los  algoritmos  mas  utilizados  en  gráficos  por  computador  [Bou99].  En  el  listado  3.2  se  puede 
ver  un  ejemplo  de  las  implementaciones  de  los  diferentes  métodos  aquí  listados: 

■  Eineal:  es  el  método  de  interpolación  mas  simple,  el  cuál  obtiene  los  valores  interme¬ 
dios  entre  dos  puntos  dados,  unidos  mediante  una  línea  recta.  Cada  segmento  (delimi¬ 
tado  por  dos  puntos  de  datos)  puede  ser  interpolado  independientemente.  El  parámetro 
/i  (mu)  define  donde  estimar  el  valor  en  la  línea  interpolada,  siendo  0  en  el  primer 
punto  y  1  en  el  segundo.  Para  los  valores  intermedios  entre  los  dos  puntos  en  los  que 
se  realiza  la  interpolación,  el  valor  de  /i  oscila  entre  0  y  1. 

■  Coseno:  dado  que  la  interpolación  lineal  es  demasiado  agresiva,  a  menudo  es  desable 
suavizar  los  resultados.  Uno  de  las  formas  mas  sencillas  de  logarlo  es  aproximando  el 
valor  de  ¡x  haciendo  uso  del  coseno. 

■  Cúbica:  es  el  método  de  interpolación  mas  sencillo  que  aporta  continuidad  entre  los 
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segmentos.  Debido  a  esto  requiere  la  función  necesita  cuatro  puntos  entre  los  que 
interpolar,  llamados  yO,  yl,  y2  e  y3  en  el  listado  3.2.  Por  otra  parte,  la  constante  y  se 
comporta  de  la  misma  forma  para  interpolar  entre  los  puntos  adyacentes. 

■  Hermite:  este  método  es  parecido  al  anterior,  pero  añade  una  constante  de  tensión  y 
otro  de  Bias.  La  tensión  tensa  los  valores  interpolados  de  la  curva,  mientras  que  el  bias 
los  curva.  La  figura  3.16  muestra  una  gráfica  usando  el  método  de  Hermite  con  esas 
dos  constantes  a  0. 

Hay  que  señalar  que  los  ejemplos  del  listado  3.2  son  únicamente  unidimensionales  [Bou99] . 
Para  aplicarla  a  mas  dimensiones,  únicamente  hay  que  repetir  el  proceso  para  cada  una  de 
las  siguientes  dimensiones. 


double  linearInterpolate(double  yl,double  y2,  double  mu)  { 
return(yl  *  (1-mu)  +  y2  *  mu); 

} 

double  cosineInterpolate(double  yl,  double  y2,  double  mu)  { 
double  mu2  =  (l-cos(mu  *  PI))/2; 
return(yl  *  (1  -  mu2)  +  y2  *  mu2); 

} 

double  cubicInterpolate(  double  y0,  double  yl,  double  y2,  double  y3,  double  mu)  { 
double  aO,  al,  a2,  a3,mu2; 

mu2  =  mu*mu; 
aO  =  y3  -  y2  -  y0  +  yl; 
al  =  y0  -  yl  -  a0; 
a2  =  y2  -  y0; 
a3  =  yl; 


return(a0  *  mu  *  mu2  +  al  *  mu2  +  a2  *  mu  +  a3); 

} 

double  hermiteInterpolate(  double  yO,  double  yl,  double  y2,  double  y3, 
double  mu,  double  tensión,  double  bias)  { 
double  m0,  mi,  mu2,  mu3; 
double  a0,  al,  a2,  a3; 

mu2  =  mu  *  mu; 
mu3  =  mu2  *  mu; 


m0  =  (yl 

-  yO) 

*  (1  +  bias) 

*  (1 

-  tensión) 

/ 

2 

m0  +=  (y2 

-  yl) 

*  (1  -  bias) 

*  (1 

-  tensión) 

/ 

2 

mi  =  (y2 

-  yl) 

*  (1  +  bias) 

*  (1 

-  tensión) 

/ 

2 

mi  +=  (y3-y2)*{l-bias)*(l-tension)/2; 
a0  =  2  *  mu3  -  3  *  mu2  +  1; 
al  =  mu3  -  2  *  mu2  +  mu; 
a2  =  mu3  -  mu2; 
a3  =  -2  *  mu3  +  3  *  mu2; 

return(a0*yl+al*m0+a2*ml+a3*y2) ; 

} 

Listado  3.2:  Ejemplos  de  métodos  de  interpolación 
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Figura  3.16:  Métodos  de  interpolación.  De  izquierda  a  derecha  y  de  arriba  a  abajo:  Lineal, 
Coseno,  Cúbico  y  de  Hermite  [Bou99] 

3.7.3  Sincronización  basada  en  estado 

La  sincronización  basada  en  estado  consiste  en  un  híbrido  entre  las  dos  anteriores.  En  la 
técnica  Lockstep  determinista,  se  sincronizaba  el  estado  a  partir  de  una  serie  de  acciones 
que  se  recibian  de  los  demás  jugadores.  En  la  basada  en  interpolación,  el  servidor  realizaba 
snapshots  del  estado  del  juego  y  el  cliente  interpolaba  entre  estos  snapshots. 

En  esta  técnica,  al  servidor  envía  sólamente  la  información  mas  importante,  pero  única¬ 
mente  de  los  cuerpos  físicos  con  mayor  prioridad.  Se  delega  en  el  motor  de  físicas  que  eje¬ 
cutará  el  cliente  la  labor  de  extrapolar  los  valores  de  los  atributos  de  los  cuerpos  físicos  que 
el  servidor  no  envía,  pero  se  usa  la  información  que  sí  envía  el  servidor  para  garantizar  que 
la  sincronización  es  correcta.  Típicamente  se  envía  una  estructura  como  la  del  listado  3.3. 
Usando  la  velocidad  lineal  y  la  angular,  así  como  la  posición  es  todo  lo  que  necesita  el  motor 
de  físicas  para  sincronizar  el  estado  de  los  objetos  de  la  escena. 

Ea  principal  diferencia  con  la  sincronización  basada  en  interpolación,  es  que  aquella  el 
servidor  envia  el  estado  de  todos  y  cada  uno  de  los  objetos  de  la  escena,  a  diferencia  de  la 
basada  en  estado,  que  sólo  envía  la  de  los  objetos  mas  importantes  por  orden  de  prioridad,  y 
de  estos  sólo  envía  unos  cuantos  atributos  clave  para  garantizar  la  sincronización. 


struct  ObjectUpdate  { 
int  Índex; 
vec3f  position; 
quat4f  orientation; 
vec3f  linear_velocity; 
vec3f  angular_velocity; 

}; 
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struct  Packet  { 
uintl6_t  sequence; 

Input  input; 

int  num_object_updates ; 

Obj  ectUpdate  object_updates [MaxObjectUpdatesPerPacket ] ; 

}: 


Listado  3.3:  Ejemplo  de  paquete  usado  en  sincronización  basada  en  estado 
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3.8  Middleware  orientado  a  objetos 

Los  modelos  de  red  y  técnicas  de  sincronización  abordados  en  las  secciones  anteriores 
requieren  de  un  software  de  red  que  implemente  todas  las  operaciones  descritas.  Debido  a  la 
complejidad  de  las  técnicas  mencionadas,  implementar  la  que  mejor  se  ajuste  a  las  necesida¬ 
des  de  este  proyecto  utilizando  sockets  escapa  por  mucho  al  alcance  de  un  TFG.  Por  ello,  se 
hace  necesario  el  uso  de  un  middleware  de  comunicaciones. 

Un  Middleware  es  una  capa  software  que  suele  situarse,  por  lo  general,  entre  el  Sistema 
Operativo  y  el  software  de  usuario.  Generalmente,  descarga  al  ingeniero  de  tareas  muy  con¬ 
cretas  concernientes  a  una  faceta  dada.  En  el  caso  que  nos  ocupa,  lo  abstrae  de  la  labor  de 
poner  en  contacto  un  cliente  con  un  servidor;  es  decir,  el  objetivo  ideal  de  cualquier  middle¬ 
ware  de  comunicaciones  es  ofrecer  una  visión  abstracta  al  programador  sobre  la  tecnología 
de  red  que  se  utiliza  en  la  comunicación  de  las  aplicaciones.  Aunque  en  principio  este  tipo 
de  software  no  está  ligado  a  un  modelo  de  red  concreto,  en  lo  sucesivo  se  supondrá  que  se 
está  usando  una  arquitectura  cliente- servidor. 

Figura  3.17:  Ejemplo  de  invocación  de  un  objeto  remoto  desde  el  cliente  al  servidor 


Existes  múltiples  tipos  de  middleware:  orientados  a  procedimientos,  a  mensajes,  a  compor¬ 
tamiento,  a  objetos  y  a  mensajes;  sin  embargo,  aquí  discutiremos  los  middleware  orientados 
a  objetos.  Un  middleware  de  red  Orientado  a  Objetos  (OO)  permite  realizar  invocaciones  a 
objetos  remotos,  abstrayendo  al  programador,  lo  que  en  definitiva  es  como  si  invocase  obje¬ 
tos  locales  del  propio  cliente.  Este  tipo  de  middleware  resulta  muy  útil  a  la  hora  de  programar 
el  modelo  de  red  de  un  videojuego.  Esto  es  así  porque  la  labor  de  programación  de  un  video¬ 
juego  es  muy  exigente,  y  tener  un  mecanismo  de  alto  nivel  que  la  facilite  agiliza  mucho  el 
proceso  de  implementación  y  de  diseño. 

En  la  figura  3.17,  se  observa  una  invocación  de  un  objeto  que  reside  en  la  memoria  del 
servidor.  En  dicha  figura  se  ejemplifica  una  de  las  típicas  invocaciones  que  podría  hacer  un 

7 1 

^  http  ://gafferongames . com/networked- physics/state- synchronization/ 
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cliente  de  videojuego  de  carreras  en  red:  uno  de  los  clientes  indica  al  servidor  que  está  listo 
para  que  comience  la  carrera.  Para  el  cliente,  todo  la  comunicación  de  red  es  transparente,  lo 
que  se  traduce  en  una  invocación  de  un  objeto  como  si  fuese  local. 

Los  middleware  de  red  orientados  a  objetos  aportan  una  gran  cantidad  de  facilidades  al 
programador,  pero  con  un  coste.  Debido  a  toda  la  lógica  subyacente  que  permite  que  estos 
mecanismos  de  alto  nivel  sean  posibles,  el  middleware  añade  una  sobrecarga  a  las  comu¬ 
nicaciones.  Los  mensajes  entre  el  cliente  y  el  servidor  tienen  una  cabecera  adicional,  que 
aumenta  el  tamaño  de  los  mensajes.  Además,  la  necesidad  de  analizar  dicha  cabecera  tam¬ 
bién  aumenta  lévemente  la  latencia,  debido  a  que  aumenta  el  tiempo  de  procesamiento. 

Existe  una  gran  variedad  de  middlewares  en  el  mercado  que  cumplen  con  las  caracterís¬ 
ticas  descritas  aquí.  Sin  embargo,  se  estudiará  mas  detenidamente  ZeroC  ICE,  que  será  el 
empleado  durante  el  desarrollo  de  este  proyecto. 

3.8.1  ZeroC  ICE 

ZeroC  Internet  Communications  Engine  (ICE)  [ICEb]  es  un  middleware  de  red  OO  desa¬ 
rrollado  por  la  empresa  ZeroC  y  distribuido  bajo  licencia  GPL.ICE  soporta  múltiples  lengua¬ 
jes  y  es  multiplataforma,  lo  que  proporciona  una  gran  flexibilidad  para  construir  sistemas 
muy  heterogéneos  o  integrar  sistemas  existentes. 

Al  ser  un  middleware  de  comunicaciones  OO,  ICE  está  basado  en  una  arquitectura  cliente- 
servidor.  Para  establecer  la  comunicación  entre  estas  dos  entidades  el  cliente  necesita  un 
proxy  al  objeto  para  poder  solicitar  sus  servicios  y  el  objeto  tiene  que  ser  añadido  a  un 
adaptador  de  objetos  para  que  el  cliente  pueda  acceder  a  él  a  través  del  middleware.  En  la 
figura  3.18  se  muestra  una  visión  general  de  esta  arquitectura.  En  las  siguientes  secciones  se 
definirán  algunos  de  los  elementos  mas  importantes  de  la  arquitectura  de  ICE. 


Server  Application 

í 

1 

Ice  API 

Skeleton 

Object 

— 

Adapter 

Server  Ice  Core 

□  Ice  API 
I  I  Generated  Code 


Eigura  3.18:  Estructura  de  comunicación  cliente-servidor  en  ICE 
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https  ://doc . ze roe. com/di splay/Ice36/Client+and+Server+Structu re 
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Adaptador  de  objetos 

El  adaptador  de  objetos  es  un  mecanismo  que  actúa  como  contenedor  de  los  objetos  del 
servidor  que  son  accedidos  mediante  invocaciones  remotas.  Cada  adaptador  de  objetos  tiene 
una  o  varias  direcciones  asignadas  que  son  conocidas  como  endpoints.  Cada  endpoint  se 
identifica  mediante  una  cadena  que  contiene  el  protocolo  de  transporte  utilizado,  la  dirección 
IP  y  el  puerto.  Se  puede  ver  un  ejemplo  de  endpoint  a  continuación: 

tcp  -h  127.0.0.1  -p  10000 

En  el  que  se  indica  que  se  utilizará  el  protocolo  de  transporte  TCP,  se  escuchará  por  la 
interfaz  localhost  y  en  el  puerto  10000. 

Sirviente 

El  sirviente  es  un  instancia  del  objeto  remoto  que  recibe  las  invocaciones.  Eos  sirvientes 
son  los  objetos  que  se  añaden  a  los  adaptadores  de  objetos  para  que  puedan  recibir  solicitudes 
del  exterior.  El  cliente  realizará  las  llamadas  remotas  mediante  un  objeto  proxy  proporcio¬ 
nado  por  el  middleware. 

Proxy 

Un  proxy  es  una  representación  de  un  objeto  remoto,  definido  por  una  entidad  y  un  end- 
point.Por  ejemplo: 


Identity  -t  :  tcp  -h  127.0.0.1  -p  10000 

Ea  opción  -t  indica  el  modo  de  acceso  al  objeto.  Significa  twoway,  es  decir,  el  sirviente 
recibe  peticiones  y  se  espera  una  respuesta.  Hay  otras  posibles  opciones,  como  por  ejemplo 
-o  (oneway)  donde  el  objeto  recibe  peticiones  y  pero  no  responde  a  ellas. 

Communicator 

El  Communicator  es  el  elemento  más  importante  del  middleware.  Proporciona  la  comu¬ 
nicación  entre  los  clientes  y  los  servidores  en  el  sistema  distribuido.  Se  encarga  de  crear  los 
adaptadores  de  objetos,  proxys,  identidades  de  objetos, ... 

Slice 

Specification  Eanguage  for  Ice  (Slice)  es  un  lenguaje  que  se  utiliza  para  describir  las 
operaciones  sobre  las  que  los  clientes  pueden  hacer  invocaciones.  Aquí  se  define  la  interfaz 
y  las  operaciones  que  serán  accesibles  mediante  un  proxy  a  un  sirviente  determinado  y  se 
establecen  independientemente  del  lenguaje  de  programación  que  se  vaya  a  utilizar.  ICE  pro¬ 
porciona  herramientas  para  traducir  la  interfaz  Slice  en  diferentes  lenguajes.  Eos  lenguajes  a 
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los  que  ICE  da  soporte  son  C++,  Python,  Java,  .NET,  PHP,  Objective-C,  Ruby  y  ActionScript. 
En  el  listado  3.4  se  muestra  un  ejemplo  sencillo  de  Slice. 


module  Tinman  { 
interface  Game  { 
void  start( ) ; 
void  shutdownO; 

} 

} 


Eistado  3.4:  Ejemplo  de  interfaz  Slice 


Servicios 

ICE  ofrece  una  serie  de  servicios  que  gestionan  otras  características  para  propósitos  más 
concretos: 

■  IceStorm 

IceStorm  [icea]  es  un  servicio  que  proporciona  comunicaciones  entre  clientes  y  servi¬ 
dores  mediante  la  creación  de  canales  de  eventos.  En  este  ámbito  se  habla  de  publica- 
dor  y  suscriptor  en  vez  de  cliente  y  servidor.  Eos  publicadores  envían  datos  al  canal 
mediante  invocaciones  remotas  que  serán  enviadas  a  los  suscriptores  de  dicho  canal. 
De  este  modo,  un  único  evento  de  un  publicador  puede  ser  enviado  a  múltiples  sus¬ 
criptores.  Cada  canal  está  identificado  unívocamente  por  un  nombre  y  puede  tener  a  su 
vez  múltiples  publicadores  y  múltiples  suscriptores. 

Eos  eventos  IceStorm  son  unidireccionales,  es  decir,  el  publicador  no  recibe  respuestas 
desde  los  suscriptores. 

Una  de  las  características  de  este  servicio  es  \di  federación.  Ea  federación  permite  reali¬ 
zar  enlaces  entre  canales.  Cada  enlace  es  una  asociación  unidireccional  desde  un  canal 
o  otro  y  tiene  asociado  un  coste  que  puede  limitar  la  entrega  en  ese  canal. 

Estos  enlaces  hacen  que  los  eventos  publicados  en  un  canal  también  sean  publicados 
en  todos  los  canales  que  estén  enlazados  a  él  con  coste  que  no  exceda  del  indicado  en 
el  momento  de  la  creación  del  enlace. 

Ea  figura  3.19  representa  un  ejemplo  de  federación  de  canales.  El  canal  TI  tiene  en¬ 
laces  a  T2  y  T3.  Eos  suscriptores  SI  y  S2  reciben  todos  los  eventos  publicados  en  T2 
así  como  los  publicados  en  TI.  El  suscriptor  S3  sólo  recibe  los  eventos  de  TI  y  el 
suscriptor  S4  recibe  los  eventos  de  TI  y  T3. 

Este  servicio  es  el  más  relevante  ya  que  será  utilizado  en  el  desarrollo  de  este  proyecto. 

■  IceGrid  IceGrid  es  un  servicio  de  localización  y  activación  para  las  aplicaciones  ICE. 

https  ://doc . zeroc . com/display/Ice36/IceStorm+Concepts 
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Figura  3.19:  Federación  de  canales  IceStorm^^ 


Esto  permite  que  un  cliente  se  comunique  con  un  objeto  remoto  sin  saber  en  qué  má¬ 
quina  y  en  qué  puerto  está  (proxies  indirectos). 

Una  de  las  características  de  IceGrid  es  la  activación  de  los  servidores  bajo  demanda, 
es  decir,  cuando  un  cliente  realiza  una  solicitud  a  un  objeto  en  el  servidor. 

IceGrid  permite  la  replicación  mediante  la  agrupación  de  los  adaptadores  de  objetos 
de  varios  servidores  en  un  único  adaptador  de  objetos  virtual  y  el  balanceo  de  carga. 
Además,  soporta  interfaces  que  proporcionan  a  las  aplicaciones  un  control  sobre  su 
actividad  y  notificaciones  acerca  de  eventos  significativos,  lo  que  permite  el  desarrollo 
de  herramientas  personalizadas. 

■  IceBox 

IceBox  es  un  servidor  de  aplicaciones  que  gestiona  el  arranque  y  detención  de  distintos 
componentes  de  una  aplicación. 

El  servidor  IceBox  se  configura  a  través  de  las  propiedades  de  los  servicios  de  la  apli¬ 
cación.  Estos  servicios  se  pueden  administrar  de  forma  remota  y  compartir  una  interfaz 
común  que  permite  una  administración  centralizada. 

■  IcePatch 

IcePatch  es  un  servicio  que  permite  la  distribución  de  actualizaciones  de  software  a  los 
nodos  que  componen  el  grid.  El  servicio  comprueba  automáticamente  la  versión  que 
tiene  cada  nodo  y  envía  las  actualizaciones  disponibles.  Esta  comunicación  se  puede 
realizar  de  forma  segura  utilizando  el  servicio  Glacierl  mencionado  más  adelante. 

■  Glac¡er2 

Glacierl  es  un  servicio  de  firewall^"^  que  permite  una  comunicación  segura  entre  clien¬ 
tes  y  servidores.  Los  datos  que  se  transportan  entre  clientes  y  servidores  están  encrip- 
tados. 

^^Sistema  que  permite  bloquear  los  accesos  no  autorizados,  así  como  permitir  los  autorizados. 
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■  Freeze 


Freeze  ofrece  un  servicio  de  persistencia  que  le  permite  guardar  el  estado  de  los  objetos 
ICE  en  una  base  de  datos  Berkeley^^  con  muy  poco  esfuerzo.  Freeze  puede  recuperar 
automáticamente  bajo  demanda  los  objetos  de  una  base  de  datos  y  actualizarla  cuando 
cambia  el  estado  de  un  objeto. 


3.8.2  COREA 

Common  Object  Request  Broker  Architecture  (COREA)  [COR]  es  un  estándar  definido 
por  Object  Management  Group  (OMG)  para  la  programación  de  aplicaciones  distribuidas. 
COREA  es  una  de  las  arquitecturas  actualmente  más  extendida.  Permite  que  los  componentes 
puedan  estar  escritos  en  diferentes  lenguajes  y  ejecutarse  en  diferentes  máquinas.  El  modelo 
cliente-servidor  de  COREA  (figura  3.20)  es  muy  parecido  al  de  ICE.  Se  utilizan  interfaces 
IDE  para  la  comunicación  entre  dos  o  más  aplicaciones. 


Cliente 


Invocación 

dinámica 


Sirviente 


IDL 

stubs 

Interfaz 

ORB 

Esqueleto  IDL 
estático 

Esqueleto 

dinámico 

T 


Adaptador 
de  objetos 


Puede  haber  múltiples  adaptadores  de  objetos 
Interfaz  idéntica  para  todos  los  ORB 


I  I  Hay  un  stub  y  un  esqueleto  para  cada  interfaz  IDL 
Interfaz  dependiente  del  ORB 


Figura  3.20:  Arquitectura  COREA^^ 


Una  parte  esencial  de  la  arquitectura  COREA  es  el  Object  Request  Broker  (ORE)  que  se 
encarga  de  facilitar  la  comunicación  entre  objetos,  es  decir,  es  el  encargado  de  enviar  las 
invocaciones  realizadas  por  los  clientes  y  de  retornar  las  repuestas  a  los  mismos. 

El  estándar  COREA  especifica  un  protocolo  de  transporte  llamado  General  Inter-ORB  Pro- 
tocol  (GIOP)  para  las  comunicaciones  entre  varios  componentes  OREs  e  Internet  Inter-ORB 
Protocol  (IIOP)  es  el  protocolo  utilizado  para  redes  TCP/IP. 

Existen  muchas  implementaciones  del  estándar  COREA  tanto  privativas  como  libres.  Algu¬ 
nos  ejemplos  son  TAO  [TCOlO],  OpenFusion  CORBA  [OPC]  y  ORBit2  de  GNOME  [GNO04] 

3.8.3  Java  RMI 

Java  Java  Remóte  Method  Invocation  (RMI)  [Ora]  es  un  middleware  que  fue  creado  por  la 
empresa  Sun  Microsystems  para  aplicaciones  Java.  En  la  figura  3.21  se  muestra  la  aruitectura 

^^Eiblioteca  de  software  que  proporciona  una  base  de  datos  integrada  de  alto  rendimiento  para  los  datos  con 
formato  clave/valor. 

^®Imagen  original: htt p ://cnlart  .web .  cern .  ch/cnlart/2000/002/kde- gnome3/orb . gif 
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cliente-servidor  de  RMI. 


Figura  3.21:  Estruetura  RMI^’ 


El  esquema  general  de  funeionamiento  es  el  siguiente: 

■  Cada  objeto  registrado  en  el  rmiregistry  tiene  que  implementar,  al  menos,  la  interfaz 
Remóte  para  que  pueda  ser  aeeesible.  Esta  interfaz  se  eneuentra  en  la  biblioteea  estándar 
de  RMI 

■  El  servidor  utiliza  el  rmiregistry  para  registrar  los  diferentes  objetos  que  serán  aeee- 
sibles  para  los  olientes.  RMI  utiliza  un  sistema  de  nombres  graoias  al  oual  el  servidor 
identifioa  a  oada  uno  de  los  objetos  dentro  del  rmiregistry 

■  El  cliente  obtiene  la  referenoia  a  los  objetos  que  el  servidor  publicó  a  través  del  rmi¬ 
registry 

■  Por  último,  el  oliente  puede  invoear  métodos  sobre  los  objetos  remotos,  utilizando 
la  referencia  obtenida  previamente  de  forma  muy  pareeida  a  si  el  objetio  estuviese 
aeeesible  looalmente. 

En  el  oaso  de  RMI  el  oontrato  entre  oliente  y  servidor  se  espoifioa  utilizando  interfaees 
Java.  Por  ello,  el  lenguaje  de  la  implementaeión  tanto  de  los  clientes  oomo  de  los  servidores 
que  utilicen  RMI  solamente  puede  ser  Java. 

Hasta  ahora  se  ha  dado  una  visión  de  los  oonoeptos  relaoionados  oon  las  redes  tanto  den¬ 
tro  oomo  fuera  del  desarrollo  de  un  videojuego.  A  oontinuaeión,  se  hablará  brevemente  de 
qué  es  un  motor  de  videojuegos,  y  de  la  importanoia  que  tiene  dentro  del  desarrollo  de  un 
videojuego. 

3.9  Técnicas  en  desarrollo  de  videojuegos 

Hasta  ahora  se  ha  dado  una  visión  general  de  las  materias  mas  importantes  relaeiona- 
das  eon  el  desarrollo  de  videojuegos.  En  esta  seeeión  se  intentará  mostrar  de  qué  forma  un 

97 

https  ://docs .Oracle . com/j  avase/tutorial/rmi/overview. html 
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desarrollador  puede  aplicar  técnicas  de  testing  sobre  un  videojuego  y  las  ventajas  que  estas 
aportan  sobre  el  producto  final. 

Un  videojuego  es  un  software  complejo  con  un  handicap  adicional  que  no  tienen  otros 
tipos  de  software:  el  mas  mínimo  error  hace  que  el  proceso  de  renderizado  produzca  resul¬ 
tados  indeseados  que  hacen  que  se  deteriore  la  experiencia  del  usuario.  Por  ejemplo,  en  un 
juego  de  carreras,  un  pequeño  error  en  el  algoritmo  de  inteligencia  artificial  puede  provocar 
que  los  vehículos  controlados  por  la  máquina  no  fuesen  capaces  de  terminar  la  carrera,  re¬ 
corriesen  el  circuito  en  sentido  contrario,  no  tomasen  bien  las  curvas,  saliesen  del  circuito  y 
no  supieran  volver  a  él,  etcétera.  En  cualquier  otro  tipo  de  software,  estos  errores  pasarían 
inadvertidos,  porque  aunque  el  comportamiento  del  algoritmo  no  sea  perfecto,  podría  darse 
el  caso  de  que  sea  lo  suficientemente  bueno  como  para  no  tener  que  seguir  optimizándolo. 
Sin  embargo,  en  un  videojuego  todos  estos  errores  saltan  a  la  vista,  lo  que  hace  que  el  nivel 
de  optimización  que  a  alcanzar  es  mucho  mayor  que  en  otros  proyectos. 

Por  otra  parte,  aunque  la  presencia  de  errores  en  muchos  casos  es  manifiesta,  no  lo  es  así 
la  fuente  del  error.  Debido  a  la  gran  cantidad  de  módulos  que  interaccionan  entre  sí,  y  la 
complejidad  de  los  mismos  y  de  sus  interacciones,  no  es  nada  trivial  depurar  este  tipo  de 
software.  Por  tanto,  es  necesario  realizar  un  cambio  en  la  forma  en  que  se  desarrolla  este  tipo 
de  software. 


Detailed  x  Detallad  x  Detailed  \  _  7x  t  x  ñi  \  ..  .  ^  ^ 

Planning  /  Analysis  /  Design  /  Development^  Testing  ^  Release  ^  Ma.rtenance  ^ 


Figura  3.22:  Diferentes  metodologías  de  gestión  de  proyectos.  Arriba,  Cascada.  Abajo,  Pro¬ 
ceso  Ágil^^ 

Tradicionalmente,  los  proyectos  software  han  seguido  una  metodología  en  Cascada.  Dicha 
metodología  se  caracteriza  por  tener  unos  ciclos  de  desarrollo  muy  largos,  con  unas  fases 
rígidas  y  bien  definidas.  Estas  fases  se  pueden  ver  en  la  figura  3.22  y  son: 

■  Planificación:  se  realiza  una  estimación  del  tiempo  que  tomará  el  desarrollo  del  pro¬ 
yecto.  Esta  planificación  se  intentará  mantener  a  lo  largo  del  desarrollo,  realizando 
pequeñas  modificaciones  cuando  surjan  contingencias. 

20 

^  http ://www. allaboutagile . com/agile- development- cycle/ 
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■  Análisis:  se  realiza  un  estudio  detallado  del  proyecto,  intentando  descubrir  cuáles  son 
las  necesidades  de  los  usuarios,  de  forma  que  sea  posible  determinar  los  objetivos 
que  se  cumplirán  a  lo  largo  del  proyecto.  El  resultado  de  esta  fase  es  el  documento  de 
especificación  de  requisitos,  que  contiene  una  definición  completa  de  los  requisitos  del 
sistema  sin  entrar  en  detalles  técnicos.  Este  documento  define  de  forma  rígida  todos 
los  requisitos  del  proyecto,  no  permitiendo  modificaciones  posteriores. 

■  Diseño:  Se  crea  una  arquitectura  modular  del  sistema,  que  da  como  resultado  el  docu¬ 
mento  de  diseño  del  software,  el  cuál  contiene  la  descripción  de  la  estructura  relacional 
global  del  sistema,  así  como  la  definición  del  cometido  de  cada  uno  de  los  módulos 
individuales  que  componen  el  sistema.  Ea  etapa  de  diseño  se  realiza  en  dos  fases:  una 
primera  en  la  que  se  realiza  un  análisis  de  alto  nivel,  y  una  segunda  en  la  que  se  defi- 
nene  los  algoritmos  necesarios  para  solucionar  problemas  de  mas  bajo  nivel. 

■  Desarrollo:  se  implementan  cada  uno  de  los  módulos  del  sistema  por  separado.  Nor¬ 
malmente  no  se  realizan  pruebas  de  sistema  para  comprobar  que  lo  que  se  está  desa¬ 
rrollando  funciona  correctamente. 

■  Pruebas:  en  esta  fase  se  escriben  test,  tanto  unitarios  como  de  sistema,  con  los  que 
se  intenta  eliminar  la  mayor  cantidad  de  errores  del  software  programado  en  la  etapa 
anterior. 

■  Entrega:  se  entrega  el  software  al  cliente. 

■  Mantenimiento:  fase  final  del  ciclo  de  desarrollo  en  cascada,  donde  se  realiza  un  tra¬ 
bajo  periódico  de  reestructuración  del  software  para  cumplir  con  los  requisitos  que 
durante  todo  el  resto  de  fases  el  equipo  de  desarrollo  se  negó  a  cumplir. 

Ea  metodología  de  desarrollo  en  cascada  es  una  metodología  rígida,  que  no  se  adapta  a  la 
naturaleza  cambiante  del  software.  Obliga  a  realizar  estimaciones  estrictas  en  un  ámbito  don¬ 
de  incluso  ingenieros  software  con  décadas  de  experiencia  no  son  capaces  de  hacerlas  y  tiene 
ciclos  de  desarrollo  que  pueden  llegar  incluso  al  año,  momento  para  el  cuál  las  necesidades 
del  cliente  han  cambiado  tanto  que  lo  que  se  ha  desarrollado  no  le  aporta  valor. 

Como  alternativa  a  las  metodologías  de  desarrollo  tradicionales  surgieron  lo  que  se  conoce 
como  metodologías  de  desarrollo  ágil.  Este  conjunto  de  metodologías  se  caracterizan  por 
tener  ciclos  de  trabajo  de  entre  1  semana  y  1  mes,  buscando  en  todo  momento  crear  entrégales 
ejecutables  que  aporten  valor  al  cliente.  Por  otra  parte,  este  tipo  de  metodologías  incluyen 
al  cliente  en  el  proceso  de  desarrollo,  haciéndolo  partícipe  de  él,  y  aceptando  todo  tipo  de 
ideas  y  sugerencias.  El  ciclo  de  vida  de  un  proyecto  ágil  se  puede  ver  en  la  figura  3.22. 
En  dicha  figura,  se  observa  cómo  el  proceso  de  desarrollo  ágil  sigue  un  ciclo  iterativo  e 
incremental,  donde  cada  una  de  las  iteraciones  se  sustentan  sobre  las  anteriores  y  aportan 
nueva  funcionalidad. 

A  diferencia  de  la  metodología  en  cascada,  debido  a  que  la  duración  de  las  iteraciones 
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no  supera  el  mes  y  que  se  da  mucho  mas  peso  a  la  fase  de  testing,  las  metodologías  ágiles 
pueden  adaptarse  a  los  cambios  que  les  proponga  el  cliente,  lo  que  al  final  se  traduce  en  un 
software  que  se  adapta  mejor  a  sus  necesidades. 

Un  videojuego  se  presta  a  crear  pequeños  prototipos  funcionales  que  permitan  mostrar, 
por  ejemplo,  diferentes  mecánicas  de  juego.  Esto  ayuda  a  conseguir  un  producto  mucho  mas 
pulido,  ya  que  las  pequeñas  iteraciones  y  testing  constante  hacen  que  el  código  desarrollado 
contenga  muchos  menos  bugs.  Pero  para  ello,  los  equipos  de  desarrollo  deben  prestar  la 
atención  que  merece  el  proceso  de  testing,  y  realizar  esfuerzos  para  aplicarlo. 


Pre-producción  Producción  Poslproduccción 


Figura  3.23:  Flujo  de  trabajo  en  un  proyecto  de  desarrollo  de  un  videojuego 

A  la  hora  de  aplicar  testing  automático  a  un  videojuego,  existen  una  serie  de  dificultades 
que  hay  que  superar.  Tradicionalmente  el  proceso  de  desarrollo  de  videojuegos  seguía  el  flujo 
de  trabajo  que  se  muestra  en  la  figura  3.23.  Este  proceso  estaba  formado  principalmente  por 
cinco  fases: 

■  Desarrollo  del  concepto:  el  equipo  de  trabajo  piensa  cuál  será  la  idea  general  del  juego, 
así  como  el  género,  las  mecánicas  principales  de  juego  y  algunas  ideas  acerca  de  la 
apariencia  general  del  juego:  tipo  de  música,  ambientación,  personajes,  etcétera. 

■  Diseño:  en  esta  fase  se  detallan  los  elementos  que  compondrán  el  juego,  entre  los  que 
se  pueden  encontrar  la  historia,  el  guión  (define  los  objetivos  del  juego,  quienes  serán 
los  personajes  principales  del  juego,  en  qué  partes  se  dividirá  el  juego, ...),  arte  concep¬ 
tual  (aspecto  general  del  juego),  sonido,  mecánicas  de  juego  y  diseño  de  programación 
(detalla  aspectos  generales  de  implementación:  plataforma,  lenguaje  de  programación, 
generación  de  diagramas  UMF  de  la  arquitectura,  etcétera). 

■  Planificación:  se  describen  las  tareas  a  realizar  durante  el  desarrollo  del  proyecto  y  se 
estiman  una  serie  de  plazos  para  reuniones,  entregas,  etcétera. 

■  Producción:  se  llevan  a  cabo  todas  las  tareas  especificadas  en  la  fase  de  planificación: 
programación,  ilustración,  creación  de  las  interfaces  (menús  del  juego,  HUD),  anima¬ 
ción  y  modelado  3D  y  sonido. 

■  Pruebas:  una  vez  que  está  desarrollado  gran  parte  del  videojuego,  se  realiza  una  fase 
de  pruebas  que  se  divide  en  dos  subetapas: 
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•  Fase  Alfa:  parte  del  equipo  de  desarrollo  prueba  el  videojuego  con  el  objetivo  de 
encontrar  y  solucionar  los  errores  mas  graves. 

•  Fase  Beta:  un  grupo  de  jugadores  expertos  prueban  el  juego  en  busca  de  defectos 
menores  y  algún  defecto  de  gravedad  media  o  incluso  crítica,  aunque  no  debería 
haber  ninguno  debido  a  la  etapa  anterior 

Este  proceso  de  testing  es  completamente  manual  y  consiste  en  jugar  al  juego  de  la 
manera  en  que  se  espera  que  lo  haga  un  jugador  en  busca  de  errores. 

■  Despliegue:  se  entrega  el  videojuego  para  su  venta  al  público  y  se  prosigue  una  etapa 
de  mantenimiento,  en  la  que  se  corrigen  los  errores  que  puedan  haber  quedado  ocultos 
tras  la  etapa  de  testing. 

En  la  metodología  de  desarrollo  de  videojuegos  tradicional  se  aplica  la  fase  de  testing 
cuando  el  proyecto  está  muy  avanzado.  Esto  tiene  un  impacto  directo  en  el  coste  del  software, 
lo  que  se  conoce  como  curva  de  costes  de  cambios.  Dicha  curva  indica  que  cuanto  mas 
completo  está  el  desarrollo  el  proyecto,  mayor  es  el  coste  de  los  cambios.  Esto  es  así  debido  a 
que  cada  modificación  propuesta  supone  alterar  el  software  múltiples  puntos,  lo  que  aumenta 
los  costes. 

Por  lo  anterior  se  entiende  que  la  fase  de  testing  sea  una  de  las  mas  costosas  en  proyectos 
de  desarrollo  de  videojuegos;  sin  embargo,  existe  una  serie  de  pasos  que  se  pueden  dar  en 
pos  de  reducir  el  coste  de  esta  fase  de  desarrollo: 

■  Crear  un  bancos  de  pruebas  unitarias.  No  existe  ningún  impedimento  para  realizar 
pruebas  unitarias  sobre  las  clases  de  un  videojuego,  ya  que  la  información  que  se 
quiere  contrastar  está  contenida  en  las  propias  variables  miembro  de  la  clase. 

■  Implementar  mecanismos  que  permitan  que  una  prueba  pueda  inyectar  acciones  equi¬ 
valentes  a  las  del  jugador  humano.  Eliminando  la  necesidad  de  que  un  jugador  interac¬ 
cione  con  el  juego,  se  reduce  en  gran  medida  el  coste  de  la  fase  de  betatesting,  ya  que 
estoy  daría  pie  a  automatizar  dichas  pruebas.  Lo  importante  de  las  pruebas  automáticas 
es  que  son  repetibles  en  un  tiempo  mucho  menor  que  las  manuales,  por  lo  que  agilizan 
el  proceso  de  detección  de  errores. 

■  A  raíz  del  paso  anterior,  sería  mucho  mas  sencillo  realizar  pruebas  de  sistema,  que 
ayudasen  a  comprobar  que  las  interacciones  entre  los  distintos  módulos  del  videojuego 
son  correctas,  algo  que  es  especialmente  valioso  en  juegos  en  red. 

3.9.1  Testing  automático  en  videojuegos 

La  literatura  acerca  de  este  tema  no  es  muy  extensa  porque  es  bastante  novedoso,  aunque 
sí  que  se  han  dado  algunos  pasos  hacia  la  aplicación  de  un  proceso  de  testing  automático  en 
videojuegos. 

Por  ejemplo,  en  [Phl]  se  propone  una  forma  de  crear  un  servidor  de  integración  continua. 
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de  forma  que  se  ejecuten  las  pruebas  creadas  para  el  videojuego  cada  vez  que  se  modifique 
el  código  fuente.  Un  servidor  de  integración  continua  es  un  tipo  de  software  cuyo  objetivo 
es  compilar  y  ejecutar  automáticamente,  y  de  forma  periódica,  el  proyecto,  así  como  los  test 
que  se  hayan  generado  en  él.  Esto  permite  realizar  una  detección  temprana  de  errores  en  el 
proyecto,  ya  que  se  entrelazan  las  etapas  de  desarrollo  y  testing. 

Para  ello,  los  autores  dan  una  serie  de  pautas  que  hacen  posible  crear  pruebas  para  un 
videojuego.  En  primer  lugar,  el  juego  debe  ser  capaz  de  aceptar  parámetros  por  línea  de 
órdenes,  con  los  que  configurar  una  serie  de  características  clave  de  la  partida.  Algunos  de 
estas  características  pueden  ser: 

■  qué  escenario  se  quiere  utilizar  en  la  prueba 

■  el  número  de  frames  (imágenes  renderizadas)  que  durará  la  ejecución  del  test 

■  si  es  en  red  o  contra  la  lA,  el  número  de  jugadores  que  participarán 

En  el  listado  3.5  se  puede  un  ejemplo  de  cómo  se  lanzaría  el  juego  con  estos  paráme¬ 
tros. 


game  -levelname  PalaceGate  - runforf rames  100 

Eistado  3.5:  Ejecución  guiada  de  un  videojuego 

Por  otra  parte,  en  el  artículo  se  indica  que  las  pruebas  estarían  basadas  en  un  logger,  el 
cuál  volcaría  información  importante  del  juego  o  del  motor  de  juego  durante  la  ejecución  del 
mismo.  El  funcionamiento  básico  de  las  pruebas  automáticas  que  se  proponen  es  el  siguien¬ 
te: 

■  las  pruebas  arrancarían  el  juego  con  una  serie  de  argumentos  (nombre  del  nivel,  nú¬ 
mero  de  frames  que  durará  la  prueba,  acciones  que  realizará  el  personaje  principal, 
etcétera.) 

■  esperarían  a  que  el  juego  finalizase 

■  una  vez  finalizada  la  ejecución  del  mismo,  la  prueba  parsearía  el  fichero  de  log  gene¬ 
rado.  En  él  se  encontraría  almacenada  una  serie  de  información  relevante  acerca  de  la 
ejecución  del  videojuego.  Un  ejemplo  de  salida  de  log  típica  se  puede  ver  en  el  lista¬ 
do  3.6,  que  muestra  un  ejemplo  de  entrada  del  log,  indicando  que  ha  habido  un  error 
durante  la  aplicación  de  una  textura  llamada  goldjiligree. 

Error  -  9:46:02  -  Art  -  missing  texture  "gol(j_filigree" 

Eistado  3.6:  Ejemplo  de  línea  de  un  fichero  de  log 

Este  tipo  de  pruebas  busca  provocar  que  el  juego  falle,  arrancándolo  en  una  situación 
que  los  creadores  de  la  prueba  puedan  considerar  problemática  de  acuerdo  a  algún  criterio. 
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Por  ejemplo,  si  un  artista  erea  un  eseenario  nuevo,  una  buena  forma  de  eomprobar  que  la 
geometría  del  mismo  es  eorreeta  es  añadir  una  prueba  que  haga  que  el  personaje  prineipal 
reeorra  dieho  eseenario.  Si  existe  algún  defeeto  en  la  geometría  del  eseenario,  el  personaje 
podría  quedarse  ataseado,  o  eaer  por  algún  agujero  que  no  debería  existir.  El  motor  de  juego 
registraría  este  heeho  y  la  prueba  podría  eomprobarlo  automátieamente. 

Existen  otras  téenieas  que  ayudan  a  deteetar  errores  a  través  de  pruebas  automátieas.  Una 
de  ellas  es  haeer  que  el  personaje  prineipal  realiee  aeeiones  aleatorias  en  eada  frame.  En  el 
artíeulo  [Phl],  euando  se  arranea  el  juego  eon  el  flag  -randominput,  se  sustituye  la  instaneia 
del  objeto  del  personaje  prineipal  por  un  Moek.  Dieho  Moek  lo  que  haee  es  ejeeutar  aeeiones 
aleatorias  eada  frame. 

Al  ejeeutar  aeeiones  aleatorias  durante  un  tiempo  prologando  se  llega  a  situaeiones  donde 
un  betatester  no  podría,  por  la  enorme  eantidad  de  aeeiones  que  se  pueden  llegar  a  realizar  a 
través  a  una  prueba  automátiea. 

Existe  otra  posibilidad  para  orear  pruebas  automátieas  eonsistente  en  implementar  un  API 
alternativa  que  permita  eontrolar  el  juego  de  forma  similar  a  la  que  lo  haría  un  jugador  hu¬ 
mano,  pero  haeiendo  que  sea  la  propia  prueba  quien  realiee  estas  aeeiones.  Este  prooeso  se 
llama  Instrumentación  del  motor  de  juego  [Goo].  Como  se  ha  dado  a  entender,  la  instrumen- 
taoión  eonsiste  en  exponer  el  API  de  una  elase  oonoreta,  de  forma  que  sea  posible  invooar 
los  métodos  eon  un  meoanismo  alternativo  que  permite  eliminar  la  neoesidad  de  eontrolar  el 
juego  a  través  del  teelado  o  del  ratón. 

Esta  téonioa  no  eonsiste  en  simular  eventos  de  teelado  o  ratón,  sino  en  invoear  una  serie  de 
métodos  que  realizan  las  mismas  aeeiones  que  los  que  se  invoean  euando  un  jugador  pulsa 
algún  botón  del  teelado  o  del  joystiek,  y  además,  siguiendo  el  mismo  flujo  de  ejeeueión. 
Graeias  a  esto,  es  posible  erear  pruebas  de  sistema,  las  euales  ayudan  a  eomprobar  si  las 
interaeeiones  entre  todos  los  eomponentes  del  videojuego  funeionan  de  la  forma  en  que  se 
espera.  Este  tipo  de  pruebas  son  mueho  mas  potentes  que  los  test  unitarios,  porque  además  de 
eomprobar  que  los  valores  de  retomo  de  diferentes  métodos  son  los  que  se  esperan,  también 
eomprueban  que  las  interaeeiones  entre  las  distintas  elases  del  juego,  así  eomo  el  flujo  de 
ejeeueión  es  el  eorreeto  y  no  oeasiona  errores. 
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Capítulo  4 


Desarrollo  del  proyecto 


En  este  capítulo  se  describen  las  decisiones  tomadas  en  cada  una  de  las  iteraciones  del 
proyecto.  Cada  iteración  comienza  sobre  el  resultado  de  la  anterior  y  aporta  nuevas 
soluciones  a  problemas  existentes  en  cada  momento.  Ademas  se  discutirán  los  aspectos  mas 
relevantes  de  las  soluciones  aportadas. 


4.0  Iteración  0:  Entrenamiento  con  la  biblioteca  de  renderizado 

En  esta  primera  iteración  se  pretende  crear  un  ejemplo  mínimo  que  sirva  para  adquirir 
la  destreza  necesaria  para  poder  utilizar  OgreSD,  la  biblioteca  de  renderizado  que  se  está 
escogida  en  este  proyecto. 

4.0.1  Análisis 

OgreSD  cuenta  con  una  arquitectura  muy  compleja  (ver  figura  3.2).  Existe  una  serie  de 
conceptos  mínimos  que  se  deben  comprender  a  la  hora  de  trabajar  con  Ogre: 

■  Roof.  Es  el  objeto  principal  dentro  de  Ogre.  Internamente  está  implementado  mediante 
un  Singleton  de  forma  que  no  sea  posible  crear  mas  de  una  instancia  de  este  objeto. 
Sirve  como  fachada  a  través  de  la  cuál  realizar  cualquier  otra  operación  dentro  de  Ogre. 

■  Ventanas:  Ogre  permite  crear  y  configurar  ventanas  sobre  la  que  se  renderizarán  las 
imágenes  del  videojuego.  Permiten  capturar  eventos,  como  por  ejemplo  el  relacionados 
con  el  botón  de  cerrar,  de  forma  que  da  la  posibilidad  de  realizar  alguna  acción  que  el 
programador  crea  conveniente,  como  comenzar  el  proceso  de  cerrado  del  videojuego, 
cuando  se  pulse  dicho  botón. 

■  Gestor  de  recursos:  Este  gestor  permite  leer  y  cargar  en  memoria  los  recursos  gráficos 
necesarios,  o  assets.  Para  ello,  se  ha  de  indicar  la  ruta  de  un  fichero  de  configuración 
que  indicará  la  localización  de  dichosq  recursos.  El  gestor  se  encargará  de  cargarlos  en 
memoria,  de  forma  que  puedan  ser  utilizados  posteriormente. 

■  Gestor  de  escena:  Se  encarga  de  gestionar  todos  los  objetos  que  intervienen  dentro  de 
la  escena:  nodos  de  escena,  entidades,  luces,  sombras,  partículas,  Billboards,  Overlays, 
etcétera.  Una  escena  es  una  abstracción  del  mundo  virtual  representado  dentro  del 
videojuego. 
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■  Grafo  de  escena:  estructura  de  datos  que  utiliza  el  motor  de  renderizado  para  gestionar 
los  elementos  dentro  de  la  escena.  Dicha  estructura  está  formado  por  nodos.  Permite 
hacer  optimizaciones  sobre  el  proceso  de  renderizado,  de  forma  que  se  desestimen 
determinados  nodos  que  no  van  a  mostrarse  atendiendo  a  un  criterio  dado;  por  ejemplo, 
que  no  estén  dentro  del  área  que  enfoca  la  cámara  (el  frustrum). 

■  Nodo  de  escena:  Representa  un  elemento  de  la  escena  y  se  encarga  de  gestionar  las 
transformaciones  geométricas  que  sufran  dichos  elementos.  Permiten  encapsular  obje¬ 
tos  que  deriven  de  la  super  clase  MovableObject  (ver  4.1).  Los  nodos  de  escena  sirven 
como  una  estructura  de  datos  genérica  que  permite  abstraer  las  operaciones  geomé¬ 
tricas  de  la  lógica  del  objeto  que  está  encapsulado  dentro  del  nodo.  Debido  a  la  gran 
cantidad  de  objetos  que  heredan  de  MovableObject,  esto  permite  que  el  grafo  de  escena 
sea  muy  flexible  y  extensible. 

■  Movable  Object:  Un  objeto  de  esta  clase  está  asociado  a  un  determinado  nodo,  que 
define  su  posición.  Entre  la  gran  cantidad  de  objetos  existentes,  los  mas  importantes 
son:  Camera,  Entity,  Eight,  Billboard  y  ParticleSystem. 

■  Entity:  Es  un  MovableObject  asociado  a  una  malla  3D.  Cada  uno  de  estos  objetos 
contienen  la  información  que  permite  renderizar  un  elemento  dentro  de  la  escena.  Ea 
información  de  la  malla  3D  está  contenida  en  un  fichero  binario,  con  extensión  .mesh, 
que  cargado  por  el  gestor  de  recursos. 

■  Light:  Representa  un  foco  de  luz.  Existen  tres  tipos:  Posicional  (foco  de  luz  esférica 
que  ilumina  todo  un  área  por  igual),  Direccional  (foco  de  luz  muy  lejano  que  ilumina 
toda  la  escena  en  una  dirección  determinada)  y  Spotlight  o  Poco  (foco  de  luz  muy 
intenso  con  una  dirección  determinada.  Ea  diferencia  entre  la  direccional  y  la  tipo 
foco  es  que  la  segunda  ilumina  en  un  cono  con  un  área  limitada;  por  ejemplo,  una 
linterna. 

■  Camera:  Representa  la  cámara  mediante  la  cuál  se  muestra  la  escena.  Tiene  asociado 
un  ViewPort,  un  objeto  que  representa  el  área  que  está  en  el  encuadre  de  la  cámara. 

Como  se  puede  observar,  la  gran  cantidad  de  conceptos  que  aquí  aparecen  hacen  que  Ogre 
tenga  una  curva  de  aprendizaje  relativamente  compleja.  Por  esta  razón,  se  hace  necesario 
crear  un  ejemplo  mínimo  para  poner  en  práctica  comprender  todos  estos  conceptos. 

4.0.2  Diseño  e  Implementación 

El  resultado  de  esta  iteración  se  puede  observar  en  este  repositorio:  https://bitbucket.org/IsaacEacoba/intro- 
ogre 

En  él  se  crea  un  ejemplo  con  el  que  se  trabaja  con: 

■  El  objeto  Root,  con  el  que  se  crea  un  gestor  de  escena,  y  una  ventana. 

*  http  ://www.  og  reBd .  org/docs/api/1 . 9/class_ogre_l_l_movable_obiect .  html 
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Figura  4.1:  Jerarquía  de  hereneia  de  la  elase  Ogre::MovableObjeet^ 


■  Un  nodo  de  eseena 

■  Una  entidad,  que  se  utiliza  para  poder  eargar  y  renderizar  una  malla. 

■  Un  foeo  de  luz 

■  sombras  dinámicas  empleando  la  téeniea  Stencil  Additive.  Esta  se  earaeteriza  por  uti¬ 
lizar  plantillas  para  erear  las  sombras(5tónc//)  y  realizar  el  renderizado  de  la  eseena 
varias  veees  para  ir  representando  poeo  a  poeo  las  eontribueiones  de  luz  en  eada  zo- 
na{additive). 

En  la  figura  4.2  se  muestra  una  eaptura  de  pantalla  del  resultado  de  la  iteraeión.  En  ella  se 
puede  ver  eomo  hay  sombras  bajo  el  mentón  del  Ogro. 

4.1  Iteración  1:  Creación  de  la  primera  prueba  y  renderizado  de  un 
coche 

En  esta  segunda  iteraeión  se  pretende  erear  el  primer  test.  Se  eomenzó  a  partir  del  eonoei- 
miento  adquirido  sobre  OgreSD  en  la  iteraeión  anterior  eon  la  inteneión  de  erear  un  ejemplo 
mínimo  auto-eontenido,  que  sirva  por  un  lado  para  mostrar  el  proeeso  de  inieializaeión  del 
motor  de  renderizado,  y  por  otro,  para  eomprobar  que  se  inieializa  eorreetamente  eada  vez 
que  se  ejeeute  el  juego. 
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Figura  4.2:  Resultado  de  la  iteraeión  0 


4.1.1  Análisis 

El  objetivo  es  erear  una  prueba  que  permita  eomprobar  que  el  proeeso  de  inieializaeión 
del  motor  de  renderizado  se  lleva  a  eabo  eorreetamente.  En  este  easo,  se  eonsidera  que  lo 
mas  seneillo  pasa  por  renderizar  un  eoehe  sobre  un  eseenario  vaeío.  A  grandes  rasgos,  el 
test  asoeiado  ereará  los  objetos  neeesarios  para  poder  inieializar  Ogre,  seguirá  añadiendo  el 
eoehe  a  la  eseena  y,  por  último,  se  llamará  a  la  senteneia  que  renderizará  la  eseena,  lo  que 
mostrará  un  eoehe  sobre  un  eseenario  vaeío. 

En  este  punto  existe  un  problema,  al  que  se  debe  dar  solueión: 

■  ¿De  qué  forma  se  puede  eomprobar  que  la  prueba  efeetivamente  se  ha  ejeeutado  según 
lo  esperado?  Es  deeir,  ¿se  está  renderizando  un  eoehe  sobre  un  fondo  negro,  o  lo  que 
se  ve  en  pantalla  es  otra  eosa? 

Un  videojuego,  en  gran  parte,  está  formado  por  una  serie  de  algoritmos,  de  inteligeneia 
artifieial,  eomunieaeiones  en  red,  simulaeión  físiea,  eteétera,  que  no  se  difereneian  mueho  de 
otros  algoritmos  que  se  pudiesen  eneontrar  en  otro  tipo  de  software.  Por  esta  razón,  realizar 
pruebas  unitarias  sobre  las  elases  del  motor  de  juego  no  tiene  mayor  difieultad.  Sin  embargo, 
ya  que  un  videojuego  no  es  sino  una  aplieaeión  de  renderizado  interaetivo,  realizar  pruebas 
de  integraeión  (o  de  sistema)  sobre  uno  tiene  varios  problemas: 

■  Problemas  de  preeisión  en  eáleulos  en  eoma  flotante:  De  forma  habitual  euando  se  tra¬ 
baja  eon  biblioteeas  gráfieas,  de  red  o  motores  de  simulaeión  físiea  se  realizan  eáleulos 
en  eoma  flotante.  El  problema  radiea  en  que  existe  un  pequeño  error  en  estos  eáleulos 
debido  a  problemas  de  redondeo  del  punto  flotante,  variando  los  resultados  obtenidos 
dependiendo  de  la  arquiteetura  del  proeesador,  del  set  de  instrueeiones,  eteétera.  Esto 
signifiea  que  eon  la  misma  entrada  no  se  puede  garantizar  que  se  vaya  a  generar  la 
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misma  salida  de  forma  exacta.  Debido  a  esto,  para  comparar  valores  en  coma  flotante 
se  debe  trabajar  con  intervalos  o  truncar  el  valor  de  salida,  ya  que  una  comparación 
entre  dos  valores  que  teóricamente  deberían  ser  iguales  hará  que  la  comparación  falle. 

■  Dependencia  entre  módulos  del  motor  de  juego:  debido  a  que  típicamente  en  un  motor 
de  juego  la  mayoría  de  los  módulos  que  lo  conforman  dependen  de  otros  módulos,  que 
a  su  vez  dependen  de  otros  módulos,  realizar  una  prueba  sobre  un  módulo  concreto 
obliga  a  arrancar  todo  el  motor  de  juego;  por  ejemplo,  para  probar  que  el  comporta¬ 
miento  de  un  cuerpo  dentro  de  la  escena  es  físicamente  aceptable  se  deberá  arrancar  el 
motor  de  físicas,  pero  este  depende  del  motor  de  renderizado,  ya  que  en  un  videojuego 
no  tiene  sentido  no  renderizar  ninguna  imagen.  El  problema  de  esto  es  que  es  mucho 
mas  complejo  depurar  errores  debido  a  que  no  se  puede  estar  seguro  de  qué  módulo 
es  el  que  está  produciéndolos.  Idealmente  se  debería  lanzar  únicamente  el  módulo  que 
se  quiere  probar,  de  forma  que  intervenga  el  mínimo  código  fuente  posible  durante  la 
ejecución  del  test  en  cuestión. 

■  Necesidad  de  feedback  del  jugador:  normalmente  el  bucle  principal  del  juego  está 
orientado  a  los  eventos  que  generará  un  jugador  mediante  un  teclado/ratón  o  un  joys- 
tick.  Esto  significa  que  es  el  jugador  el  que  provoca  los  cambios  de  estado  en  el  video¬ 
juego.  Si  se  pretende  que  la  prueba  simule  el  comportamiento  de  un  jugador,  haciendo 
lo  que  uno  haría,  se  debe  añadir  al  motor  una  serie  de  mecanismos  de  instrumentación 
que  permitan  simular  esos  eventos  de  entrada.  Esto  hace  que  no  sea  posible  realizar 
pruebas  que  simulen  el  comportamiento  de  un  jugador  de  forma  inmediata,  lo  que 
complica  la  creación  y  ejecución  de  pruebas. 

■  Dificultad  y  lentitud  a  la  hora  de  comprobar  que  las  imágenes  renderizadas  son  las 
esperadas:  una  de  las  características  mas  importantes  que  debe  tener  un  test  es  que  su 
tiempo  de  ejecución  debe  que  ser  mínimo,  ya  que  deberá  ser  ejecutado  cada  vez  que 
se  quiera  lanzar  la  aplicación  para  detectar  posibles  errores  introducidos  en  el  nuevo 
código  que  se  va  escribiendo.  Unos  de  los  problema  de  los  algoritmos  de  visión  por 
computador  es  que  son  costosos  y  lentos.  Dado  que  la  idea  a  la  hora  de  crear  pruebas 
es  ejecutarlas  tras  cada  modificación  en  el  código,  habría  que  esperar  una  cantidad 
no  despreciable  de  tiempo,  lo  que  ralentizaría  el  proceso  de  desarrollo.  Otro  de  los 
problemas  de  esta  aproximación  es  que  se  estaría  dependiendo  completamente  de  un 
escenario  concreto,  corriendo  el  riesgo  de  que  la  prueba  produzca  el  resultado  previsto 
pero  el  código  de  producción  no. 


4.1.2  Diseño  e  Implementación 

Ea  solución  que  aquí  se  plantea  pasa  por  utilizar  un  log  para  registrar  eventos  importantes 
sucedidos  durante  el  proceso  de  inicialización  de  nuestro  motor  de  juego  y  comprobar  en 
la  prueba  que  dichos  mensajes  se  han  registrado.  Esta  aproximación  no  es  todo  lo  flexible 
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Figura  4.3:  Resultado  final  del  modelado  del  eoehe 


que  se  desearía,  ya  que  lo  que  se  está  haciendo  en  realidad  consiste  en  comprobar  que  el  log 
tiene  registradas  unas  cadenas  de  texto  concretas.  Sin  embargo,  esto  soluciona  el  problema  de 
comprobar  que  el  proceso  de  inicialización  del  motor  de  juego  se  realiza  correctamente. 

Como  biblioteca  de  Logs,  se  ha  utilizado  Boost.Log  [boo].  Se  ha  optado  por  el  proyecto 
Boost  por  que  es  un  estándar  de  facto  dentro  del  lenguaje  de  programación  C++.  Muchas 
de  las  características  de  Boost  se  han  ido  introduciendo  en  los  últimos  versiones  oficiales 
de  C++,  como  los  smart  pointers  que  se  encontraban  implementados  en  la  biblioteca  del 
proyecto  Boost  muchos  años  antes  de  que  se  incorporaran  a  C++. 

El  resultado  de  esta  iteración  se  puede  encontrar  en  el  directorio  example/00_render_a_- 
car^.  En  la  figura  4.4  se  muestra  el  resultado  de  la  prueba  y  en  4.3  el  resultado  final  del 
proceso  de  modelado  del  coche  que  se  ha  creado  apropósito  para  este  proyecto. 

En  el  listado4. 1  se  muestra  el  código  de  esta  primera  prueba,  la  cuál  comprueba  el  estado 
del  motor  de  juego  tras  el  proceso  de  inicialización,  la  cuál  es  parecida  a  los  mencionado  en 
la  sección  3.9.1  del  capítulo  de  antecedentes: 

describeC'a  gane",  []()  { 
std: :ifstream  game_log; 

std: :vector<std: :string>  messages  =  {"Ogre::Root  initialized" ,  "Resources  loaded", 
"SceneManager  initialized",  "Ogre: :Camera  initialized", 

"Ogre::Light  initialized",  "Car  added",  "Car  graphic  body  initialized", 

"Car  physic  body  initialized",  "Car  initialized",  "RenderLoop 
started",  "RenderLoop  ended"}; 

before_each ([&]{)  { 

Log  log; 

Game : : shared  game; 


game->new_session( ) ; 


^ver  https  ://goo .  gl/mdbFBs 
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game->session_->add(std: :make_shared<Car>() ) ; 
game->session_->realize( ) ; 

int  seconds  =  1; 
game->loop{seconds) ; 

log . flush( ) ; 

game_log .open( "config/game. log" ) ; 

}); 

itC'should  log  information" ,  [&]  { )  { 
std::string  message; 

for  (int  i  =  0;  std: :getline(game_log,  message);  ++i)  { 
Assert: :That(message,  Equals (messages [i] ) ) ; 

} 

game_log . close( ) ; 

}); 


Listado  4. 1 :  Primer  test 


La  prueba  realiza  los  siguientes  pasos: 

■  En  el  Setup  de  la  prueba(before_each( ))  se  crea  un  smart pointer  de  la  clase  Game, 
que  es  la  clase  que  engloba  el  bucle  de  renderizado.  Esta  clase  representa  una  instancia 
del  juego. 

■  Tras  esto  se  añade  una  nueva  sesión  al  juego.  Ea  clase  Session  representa  una  sesión 
de  juego,  cuya  duración  va  desde  que  comienza  la  partida  hasta  que  finaliza. 

■  A  esta  sesión  se  le  añade  un  coche  y  se  llama  al  método  realize  ( ) ,  que  inicia  el  proceso 
de  configuración  de  la  clase  Session.  Ea  función  de  dicho  método  es  la  de  configurar 
todos  los  atributos  de  la  clase  Session. 

■  El  siguiente  paso  consiste  en  invocar  al  bucle  de  juego  para  que  de  comienzo  el  juego, 
con  una  duración  de  un  segundo.  Esto  dará  como  resultado  la  imagen  renderizada  del 
coche  que  se  añadió  a  la  sesión.  Eo  importante  es  que  el  juego  esté  activo  el  tiempo 
suficiente  como  para  que  se  ejecuten  todas  las  rutinas  que  engloban  al  bucle  al  menos 
una  vez. 

■  Tras  esto,  se  utiliza  la  directiva  flush  del  Eog,  de  forma  que  sincronice  el  contenido  del 
fichero  de  texto  con  el  contenido  de  los  Sinks  del  Eog. 

■  Después  se  abrirá  dicho  fichero  de  texto,  tras  lo  cuál  se  comparará  que  cada  una  de  las 
líneas  contengan  la  frase  esperada. 

Ea  prueba  se  ha  escrito  utilizando  el  framework  de  testing  Bandit.  Cada  una  de  las  di¬ 
rectivas  que  se  ven  en  la  prueba(  describe,  before_each,  it)  son  funciones  que  reciben  como 
parámetro  una  función  lambda.  Este  framework  hace  uso  de  características  propias  del  nuevo 
estándar  de  C-t-i-l  1 . 
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Figura  4.4:  Resultado  de  la  iteraeión  1 


4.2  Iteración  2:  Entrenamiento  con  la  biblioteca  de  gestión  de  coli¬ 
siones 

En  esta  iteraeión  se  pretende  erear  un  ejemplo  mínimo  que  sirva  para  adquirir  la  destre¬ 
za  sufieiente  a  la  hora  de  trabajar  eon  Bullet  Physics,  la  biblioteea  de  físieas  y  gestión  de 
eolisiones  utilizada  en  este  proyeeto. 

4.2.1  Análisis 

Ya  se  introdujo  Bullet  Physics  en  la  seeeión  3.2.3.  Bullet  es  una  biblioteea  eompleja,  eon 
una  gran  variedad  de  funeionalidades  que  permiten  modelar  eomportamientos  físieos  basa¬ 
dos  en  las  leyes  de  Newton.  En  esta  seeeión  se  va  a  hablar  de  los  eoneeptos  que  se  deben 
eonoeer  a  la  hora  de  trabajar  eon  este  motor  de  eolisiones: 

■  El  elemento  mas  importante  en  Bullet  es  el  Mundo.  El  Mundo  dentro  de  Bullet  tiene 
varias  responsabilidades,  entre  las  que  se  pueden  destaear:  servir  eomo  estruetura  de 
datos  donde  almaeenar  los  euerpos  físieos  que  lo  eonforman  y  apliear  una  serie  de  res- 
trieeiones  a  estos  euerpos,  eomo  la  fuerza  de  la  gravedad,  deteetar  y  apliear  eolisiones 
entre  estos  euerpos  y  aetualizar  su  posieión  automátieamente  euando  se  aplique  eual- 
quier  tipo  de  fuerza  sobre  estos.  El  Mundo  tiene  diversas  implementaeiones  dentro  de 
la  bibilioteea,  dependiendo  de  si  utilizamos  euerpos  rígidos  o  fluidos. 

■  Como  se  ha  dieho,  el  mundo  físieo  esta  eompuesto  por  cuerpo  físicos.  Un  euerpo  físieo 
entra  dentro  de  las  dos  siguientes  eategorías:  euerpo  rígido  o  fluido.  Un  euerpo  rígido 
se  earaeteriza  por  tener  una  forma  inmutable.  Si  se  apliea  alguna  fuerza  sobre  un  euer¬ 
po  rígido,  su  forma  no  variará.  En  eontrapunto,  los  euerpos  fluidos  se  earaeterizan  por 
tener  formas  de  eolisión  que  pueden  variar  euando  se  apliea  una  fuerza  sobre  estas.  Eos 
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cuerpos  rígidos  tienen  comportamientos  menos  realistas  que  los  cuerpos  fluidos;  sin 
embargo,  simular  un  cuerpo  fluido  es  computacionalmente  mas  complejo  que  simu¬ 
lar  un  cuerpo  rígido,  debido  a  las  implicaciones  que  tiene  la  variabilidad  de  su  forma 
física.  Los  motores  de  colisión  de  última  generación  empiezan  a  integrar  simulación 
de  cuerpos  fluidos.  En  particular,  el  motor  Physx  de  Nvidia  cuenta  con  la  posibilidad 
de  simular  fluidos.  La  versión  3  de  Bullet  Physics  cuenta  con  simulación  de  cuerpos 
fluidos,  aunque  todavía  está  en  desarrollo  y  no  alcanza  un  rendimiento  aceptable  como 
para  llevarlo  a  un  videojuego. 

■  Los  cuerpos  físicos  cuentan  con  una.  forma  de  colisión.  Típicamente,  una  forma  de 
colisión  suele  ser  un  cuerpo  convexo  con  unas  determinadas  propiedades  en  función 
de  su  forma  geométrica,  un  coeficiente  de  fricción,  de  restitución,  una  inercia,  etcétera. 
Bullet  ofrece  una  cuantas  formas  primitivas  de  colisión: 

•  btBoxShape:  caja  definida  por  el  tamaño  de  sus  lados. 

•  btSphereShape:  esfera  definida  por  su  radio. 

•  btCapsuleShape:  capsula  alrededor  del  eje  Y.  También  existen  btCapsuleShape- 
X/Z 

•  btCylinderShape: 

•  btConeShape:  cono  alrededor  del  eje  Y.  También  existen  btConeShapeX/Z. 

•  btMultiSphereShap:  cascarón  convexo  formado  a  partir  de  varias  esferas  que  pue¬ 
de  ser  usado  para  crear  una  capsula  (  a  partir  de  dos  esferas)  u  otras  formas  con¬ 
vexas. 

Bullet  también  ofrece  formas  compuestas,  pudiendo  combinar  múltiples  formas  conve¬ 
xas  en  una  única.  Cada  una  de  las  formas  que  forman  la  malla  principal  se  llama /orma 
hija.  En  la  figura  4.5  se  muestran  las  formas  de  colisión  de  un  vehículo  (btBoxShape) 
y  del  suelo  (btBvhTriangleMeshShape) 

■  Adicionalmente,  se  tiene  el  problema  de  conectar  los  cuerpos  gráficos,  pertenecientes 
al  motor  de  renderizado  (OgreSD)  con  los  cuerpos  físicos.  Es  importante  señalar  que  el 
motor  de  renderizado  y  el  motor  físico  son  componentes  del  motor  de  juego  totalmente 
independientes  que,  a  priori,  no  cuentan  con  ningún  mecanismo  de  comunicación  entre 
ellos.  La  situación  es  la  siguiente:  supongamos  que  se  quiere  renderizar  una  esfera  a 
una  cierta  altura  sobre  el  suelo.  En  primer  lugar  habrá  que  indicarle  al  motor  de  rende- 
rizado  cómo  está  compuesta  la  escena  que  se  pretende  crear.  Por  tanto,  se  le  indicará 
que  cree  el  suelo  en  una  posición  determinada  y  una  esfera,  encima  del  anterior. 

La  función  de  los  cuerpos  gráficos  es  únicamente  la  de  ser  renderizados,  formando 
las  imágenes  de  la  escena,  pero  no  tienen  ningún  comportamiento  asociado  mas  allá 
de  esto.  Aquí  es  donde  entra  en  acción  los  cuerpos  físicos.  Estos  sí  que  tienen  un 
comportamiento  realista,  que  permite  que  los  cuerpos  interaccionen  entre  si.  Por  tanto. 
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se  deberá  indiear  al  motor  de  físieas  que  cree  un  cuerpo  rígido  con  una  forma  de 
colisión  en  forma  de  plano,  de  un  determinado  tamaño  y  en  una  determinada  posición. 
Además,  se  le  indicará  que  cree  un  cuerpo  físico  con  forma  esférica  de  un  determinado 
radio  y  a  una  determinada  posición.  Si  ejecutamos  este  ejemplo,  y  suponiendo  que 
existe  una  fuerza  de  gravedad  que  atraerá  la  esfera  hacia  el  suelo,  ocurrirá  lo  siguiente: 
el  cuerpo  gráfico  de  la  esfera  no  se  moverá  de  su  posición  inicial.  Esto  es  así  debido 
a  que  el  motor  de  físicas  no  tiene  ninguna  forma  de  indicarle  al  motor  de  renderizado 
las  posiciones  actualizadas  de  la  esfera  en  los  siguientes  frames. 


Figura  4.5:  Renderizado  de  formas  físicas  de  colisión 


4.2.2  Diseño  e  Implementación 

El  resultado  de  esta  iteración  esta  plasmado  en  el  siguiente  repositorio:  https  ://bitbucket . 
org/lsaacLacoba/intro-bullet.  Además,  enq  la  figura  4.6  se  puede  ver  una  captura  de  pan¬ 
talla  del  ejemplo  disponible  en  el  repositorio  anterior.  En  él,  se  crea  un  plano,  y  por  cada 
pulsación  de  la  tecla  B  se  crea  una  esfera,  que  rebotará  contra  el  suelo.  Si  se  pulsa  rápida¬ 
mente  se  puede  observar  cómo  las  pelotas  rebotan  entre  sí,  comprobando  como  el  motor  de 
físicas  simula  perfectamente  el  comportamiento  de  un  cuerpo  esférico. 


Integración  con  Ogre3D 

Para  resolver  el  problema  de  la  integración  entre  Bullet  Physics  y  OgreSD,  los  cuerpos 
rígidos  de  Bullet  cuentan  con  un  atributo  llamado  estado  de  movimiento{Motion  State).  Este 
Motion  State  abstrae  de  las  operaciones  de  bajo  nivel  que  se  realizan  cuando  el  cuerpo  físico 
recibe  la  influencia  de  alguna  fuerza.  De  esta  forma,  se  puede  trabajar  directamente  con  los 
cuerpos  físicos,  sabiendo  que  las  posiciones  de  los  elementos  de  la  escena  serán  adecuada¬ 
mente  actualizadas  en  función  del  movimiento  del  cuerpo  físico. 

En  resumen,  la  clase  MotionState  nos  permite  actualizar  la  posición  de  los  nodos  de  escena 
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de  Ogre.  Para  ello,  se  requiere  aportar  una  implementación,  dado  que  se  trata  de  una  clase 
abstracta. 


void  MotionState: :setWorldTransform{const  btTransform  &worldTrans) 
{ 

if (mSceneNode  ==  nullptr) 

return;  //  silently  return  before  we  set  a  node 


btQuaternion  rot  =  worldTrans . getRotation{ ) ; 

mSceneNode  ->setOrientation  (  rot .  w( ) ,  rot.x{),  rot.yO,  rot.zO); 

btVectorB  pos  =  worldTrans .getOrigin () ; 

mSceneNode  ->setPosition(pos  .x{ ) ,  pos.yO,  pos.zO); 


Listado  4.2:  Método  setWorldTransform  de  la  clase  MotionState 

La  clase  tiene  como  únicos  atributos  un  objeto  btT ransform  de  Bullet  y  un  puntero  a  Scene- 
Node  de  Ogre.  Es  dentro  del  método  setWorldT ransformí  )(ver  listado  4.2)  donde  se  realiza  la 
actualización  del  nodo  de  OgreSD.  Bullet  invoca  de  forma  automática  el  método  setWorld- 
T ransformí )  de  cada  uno  de  los  cuerpos  físicos  que  forman  el  mundo. 

Dicho  método  recibe  un  objeto  de  tipo  btTransform.  La  clase  btTransform  encapsula  un 
cuaternio,  que  almacena  la  rotación  del  cuerpo  físico,  y  un  vector,  que  almacena  su  posición. 
Dado  que  la  clase  MotionState  almacena  un  puntero  a  un  nodo  de  escena  de  OgreSD,  en  el 
momento  en  que  Bullet  invoque  el  método  setWorldT ransformí ),  se  actualizará  la  rotación  y 
posición  de  dicho  nodo  de  escena;  es  decir,  se  actualizará  la  posición  y  rotación  del  cuerpo 
gráfico  a  partir  de  la  nueva  información  recibida. 


btVectorS  inertia(0  ,0  ,0); 
if(mass  !=  0) 

shape->calculateLocalInertia(mass,  inertia) ; 
int  radius  =  1; 

MotionState*  motionState  =  new  MotionState(worldT ransform,  node); 
btRigidBody : : btRigidBodyConst ructioninfo 

rigidBodyCI (mass ,  motionState,  new  btSphereShape( radius) ,  inertia); 


btRigidBody*  rigidBody  =  new  btRigidBody ( rigidBodyCI) ; 
dynamics_world_->addRigidBody( rigidBody) ; 

Listado  4.3:  Creación  de  un  cuerpo  rígido 

Por  último,  en  el  listado  4.3  se  muestra  cómo  se  crea  un  cuerpo  rígido  con  una  forma  física 
esférica.  Es  importante  saber  que  Bullet  interpreta  que  un  cuerpo  con  una  masa  de  0  kg  es 
un  cuerpo  que  no  interacciona  con  ninguna  fuerza;  es  decir,  permanecerá  inamovible  en  su 
posición  inicial.  Por  otra  parte,  las  medidas  de  las  formas  físicas  de  colisión  de  Bullet  están 
expresadas  en  metros  desde  el  centro  de  la  forma  física.  Esto  quiere  decir  que  la  esfera  que 
se  crea  en  el  listado  4.3  es  una  esfera  de  un  metro  de  radio. 
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Figura  4.6:  Simulación  del  comportamiento  de  cuerpos  esféricos 


4.3  Iteración  3:  Gestión  de  eventos  de  usuario 

En  esta  iteración  se  pretende  implementar  la  lógiea  necesaria  para  que  el  vehíeulo  creado 
en  la  iteraeión  anterior  pueda  ser  eontrolado  por  un  jugador  usando  el  teelado.  Para  eonseguir 
esto  se  implementará  el  soporte  neeesario  para  deteetar  qué  teclas  son  pulsadas  y  ejecutar 
alguna  acción  en  respuesta. 

4.3.1  Análisis 

El  objetivo  es  eonseguir  que  el  eoehe  renderizado  en  la  iteración  anterior  pueda  ser  movido 
por  el  usuario.  Para  ello,  se  hace  necesario  el  uso  de  alguna  biblioteea  que  ayude  a  gestionar 
los  eventos  de  teelado  y  de  ratón. 

Por  otra  parte,  en  eualquier  videojuego,  normalmente  se  asignan  una  serie  de  teelas,  bien 
de  teelado  o  bien  de  un  joystiek,  a  una  serie  de  aeciones  del  juego;  en  nuestro  easo,  podría 
ser  acelerar  o  frenar  el  eoche,  haeerlo  girar,  etcétera.  En  algún  punto  del  programa  habrá  que 
comprobar  qué  teclas  se  han  pulsado  y,  en  respuesta,  ejeeutar  la  aeeión  asociada.  Por  esta 
razón,  sin  meeanismos  de  alto  nivel  que  añadan  flexibilidad  a  la  hora  de  manejar  los  eventos, 
la  solución  a  este  problema  pasa  por  crear  una  función,  que  será  invoeada  una  vez  en  eada 
iteración  del  bucle  prineipal  del  juego  y  contendrá  una  sentencia  condicional  if  por  cada 
acción  que  pueda  realizar  el  jugador.  Diehas  senteneias  eondicionales  eontendrán  el  eódigo 
asociado  a  una  determinada  tecla.  Esta  solución  no  es  flexible  ni  mantenible  ya  que  se  aeopla 
toda  la  lógiea  de  control  a  un  único  fragmento  de  código,  de  forma  que  en  el  momento  que 
se  quiera  extender  o  modifiear  será  eomplieado  eliminar  las  dependeneias  que  apareeerían 
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en  esta  situación.  Por  esta  razón  se  ha  de  buscar  una  implementación  alternativa  que  permita 
solucionar  dicho  problema. 


4.3.2  Diseño  e  Implementación 

A  la  hora  de  elegir  una  biblioteca  de  gestión  de  eventos  de  entrada,  la  elección  en  este 
proyecto  ha  sido  Object  oriented  Input  System  (OIS)  [Gam].  La  razón  de  la  elección  radica 
en  la  sencillez  de  integración  junto  a  nuestro  motor  de  juego  y  el  hecho  de  ser  multiplata- 
forma,  teniendo  soporte  para  Windows,  GNU/Linux  y  Android.  En  cuanto  a  la  funcionalidad 
ofrecida,  OIS  permite  gestionar  eventos  de  teclado,  tanto  de  pulsación  como  de  liberación  de 
teclas,  y  eventos  de  ratón:  permite  gestionar  hasta  siete  teclas  de  ratón  (con  sus  correspon¬ 
dientes  eventos  de  liberación  y  pulsado)  así  como  eventos  de  movimiento.  Además  ofrece 
soporte  para  Joystick  y  mando.  Debido  a  todas  estas  razones  OIS  cubre  todas  las  necesidades 
técnicas  que  se  tenían.  La  biblioteca  SDL  también  ofrece  el  mismo  soporte,  pero  se  optó  por 
elegir  OIS  debido  a  la  sencillez  a  la  hora  de  integrarla  con  el  motor  de  juego. 

Una  vez  elegida  la  tecnología  sobre  la  que  apoyar  el  desarrollo,  el  siguiente  paso  consiste 
en  implementar  una  clase  que  permita  gestionar  de  forma  flexible  eventos  de  teclados,  así 
como  mapear  teclas  a  callbacks. 

Estudiando  detenidamente  el  problema  se  observa  que  se  puede  resolver  utilizando  el  pa¬ 
trón  de  diseño  Reactor.  Según  [BMR+96],  este  patrón  permite  a  aplicaciones  dirigidas  por 
eventos  despachar  múltiples  peticiones  destinadas  a  una  aplicación  procedentes  de  una  o 
mas  fuentes  de  datos.  Tradicionalmente,  este  ha  sido  un  patrón  usado  en  comunicaciones  de 
red  para  resolver  los  problemas  de  asincronismo  propios  de  este  contexto  y  así  poder  reali¬ 
zar  otras  acciones  hasta  que  se  recibiesen  los  mensajes  que  se  esperan.  En  el  caso  de  este 
proyecto,  si  se  realizase  una  espera  síncrona  para  gestionar  los  eventos  de  teclado  genera¬ 
dos  por  el  usuario  no  se  podrían  realizar  otras  acciones.  Por  otra  parte,  en  nuestro  caso  sólo 
existe  una  fuente  de  datos,  el  dispositivo  que  esté  usando  el  jugador,  pero  existen  múltiples 
tipos  de  eventos  en  los  que  se  está  interesado  y  así  como  de  acciones  acciones  asociadas  a 
dichos  eventos,  de  forma  que  este  patrón  encaja  bien  para  resolver  el  problema  que  se  está 
estudiando. 


enum  class  EventType{Repeat ,  DoItOnce}; 

enum  class  EventTrigger{  OnKeyPressed ,  OnKeyReleaseíd} ; 

class  EventListener:  public  Ogre: :WindowEventListener, 
public  OIS : : KeyListener, 
public  OIS : iMouseListener  { 

typedef  bool  OnKeyPressed; 

typedef  std : : pair<0IS : ¡MouseButtonID,  EventTrigger>  MouseKey; 
typedef  std: :pair<0IS: :KeyCode,  EventTrigger>  KeyBoardKey; 

OIS: : InputPIanager*  input_manager_ ; 

0IS::Mouse*  mouse_; 
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OIS: :Keyboard*  keyboard_; 


MouseKey  niouse_key_; 

std:  :map<MouseKey,  std : :  function<void ( )»  niouse_triggers_ ; 

public : 

typedef  std ; : shared_ptr<EventListener>  shared; 
typedef  std : : vector<KeyBoardKey>  KeyEvents; 

float  X,  y; 
bool  exit_; 


EventListener(Ogre: : RenderWindow*  window) ; 


void  capture(void) ; 
void  check_events ( ) ; 

void  add_hook(MouseKey  key, std : : function<void( )>  callback); 
void  add_hook(KeyBoardKey  keystroke,  EventType  type, 

std : : function<void( )>  callback); 

void  clear_hooks( ) ; 

bool  keyPressedíconst  OIS : : KeyEvent&  arg); 
bool  keyReleased(const  OIS : : KeyEvent&  arg); 
bool  mouseMoved{const  OIS: :MouseEvent&  evt); 
bool  mousePressed(const  OIS: :MouseEvent&  evt, 

OIS: :MouseButtonID  id); 

bool  mouseReleased (const  OIS : :MouseEvent&  evt, 

OIS: :MouseButtonID  id); 


}; 


Listado  4.4:  Declaración  de  la  clase  EventListener 


void 

EventListener: :add_hook{EventListener: :KeyBoardKey  keystroke, 

EventType  type,  std : : function<void( )>  callback)  { 
if(type  ==  EventType: : repeat  &&  ! repeat_triggers_[keystroke] ) 
repea t_triggers_ [keystroke]  =  callback; 
else  if(type  ==  EventType :: doItOnce  &&  !doitonce_triggers_[keystroke] )  { 
doitonce_triggers_ [keystroke]  =  callback; 

} 

} 

void 

EventListener: : check_events (void)  { 

if (mouse_key_ . first  !=  OIS: :MB_Button7) 
trigger_mouse-events( ) ; 
if ( !events_ .empty( ) ) 

trigger_keyboard_events( ) ; 

} 

void 

EventListener: :trigger_keyboard_events( )  { 

if (events_ . size{ )  >  doitonce_triggers_. size( )  +  repeat_triggers_ . size( ) ) 

return; 
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for(auto  event:  events_){ 

if (doitonce_triggers_[event] ){ 
doitonce_triggers_[event] () ; 
remove_key_f rom_buf fer(event) ; 

} 

if { repeat_triggers_ [event] ) 
repeat_triggers_ [event] ( ) ; 

} 

} 

bool 

EventListener: :keyPressed(const  OIS : : KeyEvent&  arg)  { 

CEGUI : :GUIContext&  context  =  CEGUI :: System: :getSingleton () . 
getDefaultGUIContext ( ) ; 

context. injectKeyDown( (CEGUI: :Key: :Scan)  arg.key) ; 
context . injectChar(arg . text) ; 

remove_key_f rom_buffer( {arg . key,  EventT rigger: : OnKeyReleased}) ; 
events_ . push_back({arg . key,  EventT rigger: :OnKeyPressed}) ; 

return  true; 

} 

void 

EventListener: : remove_key_from_buffer(KeyBoardKey  event)  { 

auto  keyevent  =  find  (events_ . begin( ) ,  events_ . end ( ) ,  event); 
if(keyevent  ==  events_ . end ( ) ) 

return ; 

events_.erase{keyevent) ; 

} 

Listado  4.5:  Métodos  mas  importantes  de  la  clase  EventListener 

A  continuación  se  tratará  de  explicar  la  idea  general  del  gestor  eventos.  En  el  listado  4.4 
se  muestra  la  declaración  de  la  clase,  así  como  los  tipos  de  datos  utilizados.  En  el  listado  4.5 
se  muestra  la  implementación  de  los  métodos  mas  importantes: 

■  En  la  inicialización  del  videojuego,  se  mapea  una  serie  de  teclas  de  teclado  con  ac¬ 
ciones  del  juego.  En  el  listado  4.6  se  puede  ver  un  ejemplo  de  cómo  asociar  la  tecla 
Escape  con  el  método  shutdown( )  de  la  clase  Game. 


game_->input_->add_hook({OIS : : KC_ ESCAPE, 

EventTrigger: :OnKeyPressed}, 

EventType: :dolt0nce, 

std :  :  bind  (&Gaine :  :  shutdown ,  game_) ) ; 

Eistado  4.6:  Ejemplo  de  mapeo  tecla-acción 


En  dicho  listado  se  invoca  al  método  add_hook  de  la  clase  EventListener.  El  primer 
argumento  es  un  par  que  contiene  el  código  asociado  a  la  tecla  pulsada  y  un  tipo 
enumerado  llamado  EventTrigger.  Dicho  tipo  de  datos  indica  la  condición  bajo  la  que 
se  ejecutará  la  acción  asociada,  y  tiene  dos  posibles  valores: 
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•  OnKeyPressed:  el  evento  se  lanzará  cuando  la  tecla  asociada  sea  presionada. 

•  OnKeyReleased:  el  evento  se  lanzará  cuando  la  tecla  asociada  sea  liberada. 

El  segundo  argumento  es  de  tipo  EventType  e  indica  la  cantidad  de  veces  que  se  debe 
ejecutar  la  acción  asociada: 

•  Repeat:  la  acción  se  ejecutará  mientras  se  cumpla  la  condición  de  activación  del 
evento.  Si  la  condición  es  de  pulsado,  se  ejecutará  mientras  la  tecla  esté  pulsada 
y  si  es  de  liberado,  mientras  la  tecla  se  encuentre  liberada. 

•  DoltOnce:  la  acción  se  ejecutará  una  vez  en  cada  ocasión  que  se  cumpla  la  condi¬ 
ción  de  lanzamiento  del  evento. 

Esta  característica  es  muy  importante  ya  que,  por  ejemplo,  en  un  juego  de  coches 
el  jugador  esperará  poder  acelerar  mientras  tenga  la  tecla  de  acelerar  pulsada  y,  en 
cambio,  cuando  pulse  un  botón  de  un  menú  esperará  que  las  acciones  ejecutadas  se 
reproduzcan  una  única  vez. 

El  tercer  y  último  argumento  es  un  functor.  Un  functor  es  un  objeto  que  implementa  el 
operadorí ) ;  es  decir,  que  es  invocable.  En  el  ejemplo,  se  hace  uso  de  la  función  bind  ( ) 
de  la  biblioteca  estándar  para  crear  el  puntero  a  la  función  shutdown  ( )  de  la  clase  Game. 

Ea  función  bind  ( )  hace  muy  sencillo  crear  un  functor  de  una  función  miembro.  Exis¬ 
te  una  diferencia  fundamental  entre  invocar  una  función  e  invocar  un  método  (función 
miembro)  de  una  clase:  el  método  tiene  asociada  una  instancia  concreta  de  dicha  clase. 
Ya  que  los  objetos  tienen  un  estado  asociado,  para  poder  crear  un  puntero  a  función 
miembro  es  necesario  poder  asociar  la  información  contextual  de  la  instancia  con  di¬ 
cho  puntero.  Dicha  información  hace  posible  que  mas  adelante,  cuando  se  quiera  usar 
dicho  functor,  sea  posible  recuperar  el  estado  de  la  instancia  concreta.  Si  no  se  asociase 
la  información  contextual  de  la  instancia  con  el  functor,  no  se  sabría  a  qué  instancia  se 
está  haciendo  referencia,  con  lo  que  la  invocación  al  método  no  tendría  sentido. 

■  Durante  la  ejecución  del  juego,  cada  vez  que  el  jugador  pulse  o  libere  una  tecla,  tan¬ 
to  de  teclado  como  de  ratón,  se  invocarán  a  los  métodos  keyPressed,  keyReleased, 
mouseMoved,  mousePressed.  En  el  listado  4.5  sólo  se  muestra  la  implementación  del 
método  keyPressed  por  brevedad,  pero  los  otros  métodos  son  parecidos.  Por  tanto,  se 
va  a  explicar  únicamente  el  funcionamiento  del  método  keyPressed. 

Este  método  es  invocado  por  el  objeto  OIS; ;  inputManager  cada  vez  que  se  pulsa  una 
tecla  (declarado  en  el  listado  4.4)  y  recibe  como  argumentos  la  información  relativa 
a  la  tecla  que  ha  sido  pulsada.  Acto  seguido,  se  traduce  el  nombre  de  la  tecla  a  un 
formato  que  pueda  entender  CEGUI  (biblioteca  de  gestión  de  widget  gráficos,  que 
se  mencionará  en  secciones  posteriores)  y  se  le  inyecta  dicho  evento  para  que  pueda 
gestionarlo.  Por  último,  se  añade  el  evento  al  buffer  events_  y  se  elimina  de  él  cualquier 
aparición  del  mismo  tipo  de  evento  pero  con  una  condición  de  lanzamiento  de  liberado. 
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La  idea  del  método  remove_key_f  rom_buffer( )  es  la  de  eliminar  los  eventos  generados 
por  la  pulsación  de  una  misma  tecla  pero  con  una  condición  de  lanzamiento  contraria. 
En  este  caso,  dado  que  se  genera  un  evento  con  la  condición  de  lanzamiento  OnKey- 
Pressed,  se  eliminarán  los  eventos  con  la  misma  tecla  que  pero  con  una  condición  de 
lanzamiento  OnKeyReleased.  De  esta  forma  se  evitan  conflictos  en  la  gestión  de  eventos. 

■  La  gestión  de  eventos  finaliza  con  la  invocación  del  método  check_events  ( ) .  Este  otro 
método  iterará  sobre  el  contenedor  events_,  que  almacena  los  eventos  generados,  y 
comprobará  si  alguno  de  ellos  tiene  asociado  alguna  acción;  es  decir,  se  comprueba 
si  dicho  evento  tiene  una  entrada  en  el  mapa  repeat_triggers_  (destinado  a  eventos 
de  tipo  Repeat)  o  en  el  mapa  do_it_once( )  (destinado  a  eventos  de  tipo  DoitOnce).  De 
ser  así  se  ejecutaría  el  callback  asociado  un  número  de  veces  que  depende  del  tipo  de 
evento  que  se  acaba  de  mencionar. 

Mediante  el  uso  de  un  mapa  que  permite  asociar  teclas  con  functores  de  funciones  miem¬ 
bro,  se  elimina  el  problema  de  mantenibilidad  e  inflexibilidad  que  se  tenía  anteriormente.  Por 
un  lado,  añadir  teclas  asociadas  a  acciones  es  tan  sencillo  como  insertar  una  nueva  entrada 
en  el  mapa  anteriormente  mencionado,  tal  y  como  se  muestra  en  el  listado  4.6.  Por  otro,  en 
lugar  de  tener  numerosas  sentencias  condicionales,  se  pueden  comprobar  si  las  teclas  pulsa¬ 
das  tienen  alguna  acción  asociada  comprobando  si  dicha  tecla  existe  en  el  mapa  en  forma  de 
clave,  y  de  ser  así,  se  podría  ejecutar  la  acción  asociada. 

En  este  proyecto  se  usa  de  forma  extensiva  el  estándar  1 1  de  C-i-i-  y  en  este  ejemplo  se 
ve  reflejado,  sobretodo  en  el  listado  4.5.  El  par  que  se  pasa  como  primer  argumento  se  crea 
usando  la  inicialización  con  llaves  que  proporciona  C-t-i-l  1.  Esto  aporta  una  mayor  facilidad 
a  la  hora  de  programar  ya  que  el  compilador  crea  automáticamente  el  par. 

Además,  se  usa  el  algoritmo  find()  enelmétodo  remove_key_f  rom_buffer()  para  encontrar 
la  posición  dentro  del  buffer  de  eventos  que  ocupa  el  evento  que  se  recibe  por  argumentos. 
Por  último,  se  puede  ver  el  uso  de  la  sentencia  auto  en  el  método  t  rigger_keyboard_events  ( ) , 
lo  que  ahorra  tener  que  declarar  un  iterador,  al  hacerse  de  forma  implícita.  Con  esto  se  con¬ 
sigue  tener  un  código  mas  legible. 

El  código  fuente  de  esta  iteración  se  encuentra  en  la  rama  ogre  del  repositorio  del  proyec¬ 
to^. 

4.4  Iteración  4:  Modelado  realista  del  movimiento  del  coche 

En  esta  iteración  se  pretende  dotar  al  coche  de  un  movimiento  mas  realista,  implementando 
las  propiedades  físicas  expuestas  en  el  apartado  3.3  de  los  antecedentes. 


^https  ://bitbucket .  org/arco_group/tfg  .  tinman/src/e58677d281d67e6al4aa86639eb832cl71f4e488/src/ 
?at=ogre 


67 


4.4.1  Análisis 

Implementar  un  componente  de  dinámica  de  vehíeulos  que  permita  simular  el  movimien¬ 
to  del  eoche  de  una  forma  mínimamente  realista  no  es  algo  trivial:  se  debe  eonseguir  que  el 
vehículo  se  vea  afeetado  por  las  ondulaciones  del  terreno,  realizando  el  efecto  que  se  con¬ 
sigue  debido  a  la  amortiguación,  así  como  distribuir  dinámicamente  el  peso  entre  las  euatro 
ruedas  debido  al  efeeto  de  aceleraciones  y  frenados,  añadir  una  fuerza  de  frieeión  a  las  ruedas 
que  permita  modelar  la  traeción  de  éstas  eontra  el  terreno,  etcétera. 

Esta  última  propiedad,  la  de  frieeión,  es  una  de  las  que  mas  eomplicadas  de  implementar. 
Debido  a  las  fuerzas  que  influyen  en  el  movimiento  del  eoche,  así  eomo  la  distribución 
dinámica  de  earga,  la  traeeión  de  cada  rueda  varía  eonsiderablemente  a  lo  largo  del  tiempo, 
produciéndose  lo  que  se  eonoce  eomo  derrapes.  Sin  embargo,  debido  a  que  el  objetivo  que 
se  persigue  en  este  proyecto  es  el  de  desarrollar  un  juego  arcade,  donde  la  conducción  del 
vehíeulo  no  debe  ser  tan  realista,  esta  última  propiedad  no  será  implementada,  sustituyéndola 
por  una  modelo  estático  de  frieeión,  donde  dicha  propiedad  de  los  neumátieos  no  varíe  en  el 
tiempo. 

A  la  hora  de  implementar  todas  estas  propiedades  físicas,  se  ha  optado  por  no  reinventar 
la  rueda  y  utilizar  una  solueión  eficiente  y  bien  probada,  el  eomponente  de  dinámica  de 
vehíeulos  de  Bullet. 

Este  eomponentede  ofreee  una  implementación  de  vehíeulos  basada  en  rayqueries,  de  tal 
manera  que  se  lanza  un  rayo  por  cada  rueda  del  coehe.  Usando  eomo  refereneia  el  punto 
de  eontacto  del  rayo  eontra  el  suelo,  se  ealcula  la  longitud  y  la  fuerza  de  la  suspensión.  Ea 
fuerza  de  la  suspensión  se  aplica  sobre  el  ehasis,  de  forma  que  no  choque  eontra  el  suelo.  De 
heeho,  el  chasis  del  vehíeulo  flota  sobre  el  suelo  sustentándose  sobre  los  rayos.  Ea  fuerza  de 
frieeión  se  ealcula  por  cada  rueda  que  esté  en  eontacto  con  el  suelo.  Esto  se  apliea  como  una 
fuerza  que  permite  simular  el  comportamiento  que  tendría  un  sistema  de  suspensión. 

Hay  una  serie  de  elases  que  son  importantes  a  la  hora  de  utilizar  vehículos  en  Bullet: 

■  btRaycastVehicle:  Es  la  elase  que  modela  el  eomportamiento  del  eoche. 

■  btVehicleTuning:  elase  que  sirve  como  estructura  de  datos  para  el  almaeenamiento  de 
los  atributos  del  vehíeulo.  Eos  mas  importantes  son: 

•  btScalar  m_suspensionStiff ness:  número  en  coma  flotante  que  representa  la  ri¬ 
gidez  (stiffness)  de  la  suspensión.  Se  reeomienda  asignarle  el  valor  de  10.0  para 
todoterrenos,  50.0  para  eoehes  deportivos  y  200.0  para  eoches  de  formula  1. 

•  btScalar  m.suspensionCompression:  constante  que  representa  un  coeficiente  de 
compresión  de  la  suspensión. 

•  btScalar  m_suspensionDamping:  Coeficiente  de  descompresión  de  la  amortigua¬ 
ción  en  el  caso  de  que  esté  comprimida.  Toma  valores  entre  0  y  1.  El  valor  mí¬ 
nimo  hace  que  la  amortiguación  rebote,  mientras  que  el  valor  máximo  hace  que 
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sea  lo  mas  rígida  posible.  Entre  0.1  y  0.3  la  amortiguaeión  se  suele  eomportar 
eorreetamente. 

•  btScalar  m_maxSuspensionTravelCm:  eonstante  que  representa  la  distaneia  máxi¬ 
ma  que  puede  ser  eomprimida  la  suspensión,  expresada  en  eentímetros. 

•  btScalar  m_f  rictionSlip:  El  eoefieiente  de  frieeión  entre  el  neumatieo  y  el  suelo. 
Para  una  simulaeión  realista  debería  tomar  el  valor  de  0.8;  sin  embargo,  la  eon- 
dueeión  del  vehíeulo  mejora  al  aumentar  el  valor.  Para  eoehes  de  kart  se  aeonseja 
asignarle  valores  muy  altos  (superiores  a  10000.0). 

•  btScalar  m_maxSuspensionForce:  eonstante  que  representa  la  fuerza  máxima  que 
podría  ejereer  la  suspensión  sobre  el  ehasis.  De  esta  eonstante  depende  el  peso 
máximo  del  vehíeulo. 


4.4.2  Diseño  e  Implementación 

A  eontinuaeión  se  van  a  expliear  los  detalles  de  la  Clase  Car.  En  el  listado  4.8  se  puede  ver 
la  implementaeión  de  los  métodos  mas  importantes,  mientras  que  en  el  listado  4.7  se  puede 
ver  su  deelaraeión: 

■  En  el  eonstruetor  se  inieializa  una  serie  de  variables,  así  eomo  un  mapa  que  permite 
asoeiar  aeeiones  eon  un  eallbaek.  Este  mapa  se  usa  en  el  método  exec  ( )  para  imple- 
mentar  el  patrón  Command,  aunque  no  se  trata  de  una  implementaeión  totalmente  fiel 
al  patrón,  ya  que  este  patrón  permite  ejeeutar  una  aeeión  sin  espeeifiearla.  En  la  figu¬ 
ra  4.7  se  muestra  la  estruetura  ortodoxa  del  patrón. 


Eigura  4.7:  Patrón  Command"* 


■  Eas  aeeiones  que  puede  realizar  el  eoehe  son:  aeelerar,  frenar,  girar  a  la  dereeha  y  a  la 
izquierda  y  usar  Nitro. 


“^https  ://sourcemaking .  com/design_patterns/command 
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■  La  configuración  del  coche  se  realiza  en  el  método  realizeO.  En  dicho  método  se 
crean  el  vehículo  de  bullet,  las  formas  de  colisión  del  coche,  el  cuerpo  gráfico  del 
mismo,  se  le  indica  la  posición  inicial,  etcétera.  Es  necesario  realizar  la  inicialización 
en  el  método  realizeO  por  varios  motivos,  el  principal  es  que  se  necesita  crear  las 
instancias  del  vehículo  antes  de  renderizarlo,  de  modo  que  resulta  adecuado  realizar  el 
proceso  de  creación  y  el  de  inicialización  de  forma  separada. 

■  Dentro  del  proceso  de  inicialización,  el  vehículo  se  crea  en  varios  pasos.  En  primer 
lugar,  se  crea  el  cuerpo  rígido  que  se  usará  mas  adelante  en  el  método  init_physic_- 
bodies( ).  Tras  esto  se  i  nidal  iza  el  vehículo  en  el  método  init_raycast_car(physics). 
Este  método  recibe  una  referencia  del  gestor  de  físicas  (clase  Physics)  y  se  crea  una 
instancia  de  la  clase  btDefaultVehicleRaycaster  (que  es  una  interfaz  para  la  creación 
de  los  rayos  que  harán  de  suspensión  en  el  vehículo)  así  como  de  la  clase  btRay- 
castVehicle  (clase  que  modela  el  comportamiento  del  vehículo).  Por  último  se  aña¬ 
de  el  vehículo  recien  creado  al  mundo  físico  mediante  el  método  dynamics_world_- 
>addVehicle(vehicle_),  lo  que  lo  añadirá  a  la  simulación  física. 

■  Una  vez  que  se  ha  creado  el  coche,  se  añaden  las  ruedas.  Eas  ruedas  son  en  reali¬ 
dad  rayos  con  una  longitud,  determinada  por  la  amortiguación,  que  utiliza  Bullet  para 
calcular  el  punto  de  contacto,  así  como  otros  aspectos  como  la  fuerza  necesaria  para 
mantener  al  vehículo  suspendido  sobre  el  suelo,  aplicar  torque,  etcétera. 

■  El  último  paso  consiste  en  configurar  el  controlador  del  coche. 

class  Car  { 
public : 

typedef  std : : shared_ptr<Car>  shared; 

CarController: :shared  controller_; 

(...) 

Ogre: :SceneNode*  chassis_node_ ; 
btRigidBody*  chassis_body_ ; 

btRaycastVehicle: : btVehicleTuning  tuning_; 

btVehicleRaycaster*  vehicle_raycaster_ ; 

btRaycastVehicle*  vehicle_; 


Car(std : : string  nick); 
virtual  -'Car( ) ; 

(...) 

void  realize( Physics :: shared  physics,  Sound :: shared  sound, 

std::string  ñame,  btVectorB  position,  Ice::Byte  id); 

void  exec(Tinman: ¡Action  action); 

void  accelerate( ) ; 

void  use_nitro( ) ; 

void  stop_accelerating ( ) ; 

void  brake( ) ; 

void  stop_braking ( ) ; 

void  turn(Direction  direction); 

void  turn_right( ) ; 

void  turn_left( ) ; 
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void  stop_turning() ; 


void  update(float  delta); 

(...) 

}; 


Listado  4.7:  Declaración  de  la  parte  pública  de  la  clase  Car 


Car: :Car(std: istring  nick)  { 
nick_  =  nick; 
accelerating_  =  false; 

controller-  =  std: :make_shared<CarController>() ; 
lap_  =  0; 

current-segment-  =  Section{}; 

action_hooks [Tininan :  :Action:  :AccelerateBegin]  = 
std: :bind(&Car: :accelerate,  this) ; 
action_hooks [Tinman : :Action: :AccelerateEnd]  = 

std: :bind(&Car: : stop_accelerating ,  this) ; 
action_hooks [Tinman : :Action: :BrakeBegin]  = 
std: :bind(&Car: :brake,  this); 
action_hooks [Tinman : :Action: :BrakeEnd]  = 

std: :bind(&Car: : stop_braking ,  this) ; 
action_hooks [Tinman : :Action: :TurnRight]  = 

std: :bind(&Car: :turn_right,  this) ; 
action_hooks [Tinman : :Action: :TurnLeft]  = 

std: :bind(&Car: :turn_left,  this) ; 
action_hooks [Tinman : :Action: :TurnEnd]  = 

std: :bind(&Car: :stop_turning,  this) ; 
action_hooks [Tinman : :Action: :UseNitro]  = 

std: :bind(&Car: :use_ nitro,  this) ; 

current-segment-  =  Section{}; 
sections-covered-  =  0; 

colliding_  =  stuck_  =  can_collide_  =  false; 
colliding_time_  =  invert_direction_  =  not_moving_  =  0.f; 
std::cout  «  "[Car]  constructor"  «  std::endl; 

} 

void 

Car: :exec(Tinman: :Action  action)  { 
action_hooks[action] ( ) ; 

} 

Car: : realize(Physics : : shared  physics,  Sound : : shared  sound,  std::string  ñame, 
btVectorB  position,  Ice::Byte  id)  { 
physics-  =  physics; 
sound-  =  sound; 
id-  =  id; 

init-physiC-bodies(physics,  position) ; 
init- raycast-car(physics) ; 

add-Wheels ( ) ; 
configure- wheels( ) ; 
controller-->realize{  wheels-nodes-) ; 
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void 

Car: :init_physic_bodies(Physics: :shared  physics,  btVectorB  position)  { 
btTransform  tr; 
tr. setidentity ( ) ; 

btVectorS  origin  =  btVector3(0,  1,  0); 
compound_  =  physics-> 

create_coinpound_shape(origin,  physics->create_shape(controller_->car_dimensions_) ) ; 
collision_shapes_ .push_back(compound_) ; 


initial-positiori-  =  position; 
chassis_body_  =  physics-> 

create_rigid_body(btTransform(  initial_rotation_, position) , 

chassis_node_ ,  compound_,  controller_->mass_) ; 
chassis_body_->setDamping (0. 2 ,0.2); 

chassis_body_->setActivationState(DISABLE_DEACTIVATION) ; 

} 

void 

Car: :init_raycast_car(Physics: :shared  physics)  { 

vehicle_raycaster_  =  new  btDefaultVehicleRaycaster(physics->dynamics_world_) ; 
vehicle_  =  new  btRaycastVehicle(tuning_  ,  chassis_body_ ,  vehicle_raycaster_) ; 

physics->dynamics_world_->addVehicle(vehicle_) ; 

} 

void 

Car: :add_physic_wheel(bool  is_front,  btVectorB  connection_point ,  int  wheel_index)  { 
vehicle_->addWheel (connection_point ,  con t rolle r_->wheel_direction_cs0_ , 

control le r_->wheel_axle_cs_,  con t rolle r_->suspension_ res t_length_, 
cont roller_->wheel_radius_ , 
tuning_  ,  is_front); 

wheels_nodes_ [wheel_ Índex] ->t ranslate{connection_point . getX{ )  , 

-O.B, 

connection_point . getZ{ ) ) ; 

} 

void 

Car: :add_wheels()  { 

const  btScalar  lateral_correction  =  (O.B  *  controller_->wheel_width_) ; 
btScalar  left_wheel  =  controller_->car_dimensions_ .getX( )  -  lateral_correction ; 
btScalar  right_wheel  =  -controller_->car_dimensions_.getX()  +  lateral_correction; 
btScalar  front_wheel  =  controller_->car_dimensions_ . getZ( )  -  controller_->wheel_radius 
btScalar  rear_wheel  =  -controller_->car_dimensions_ . getZ( )  +  controller_->wheel_radius 


add_physic_wheel{true, 
add_physic_wheel{true, 
add_physic_wheel (false, 
add_physic_wheel (false, 


btVectorB (left_wheel,  controller_->connection_height- 
f ront_wheel) ,0) ; 

btVectorB ( right_wheel ,  cont roller_->connection_height- 
f  ront_wheel)  ,  1); 

btVectorB ( right_wheel ,  cont roller_->connection_height- 
rear_wheel),  2); 

btVectorB (left_wheel ,  cont roller_->connection_height- 
rear_wheel),  B); 


} 
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void 

Car: : configure_wheels ( ) { 

for  (int  i=0;  i  <  vehicle_->getNumWheels ( ) ; i++)  { 
btWheelInfo&  wheel  =  vehicle_->getWheelInfo(i) ; 
wheel .m_suspensionStiffness  =  cont rolle r_ ->suspension_stiffness_ ; 
wheel  .m_ wheel sDampingRelaxat  ion  =  cont  rolle  r_->suspension_daiTiping_ ; 
wheel .m_wheel sDampingComp res s ion  =  cont rolle r_->sus pension_ compres sion_ ; 
wheel .m_frictionSlip  =  controller_->wheel_f riction_; 
wheel. m_rollInfluence  =  controller_->roll_influence_; 

} 

} 

//Hay  muchas  funciones  que  modelan  el  movimiento. 

//Aqui  solo  se  muestran  las  de  aceleración 

void 

Car: :accelerate( )  { 
accelerating-  =  true; 
controller_->accelerate( ) ; 

} 

void 

Car : : stop_accelerating ( )  { 
accelerating_  =  false; 
controller_->stop_accelerating( ) ; 

} 

(...) 

void 

Car: : update(float  delta)  { 
update_lap( ) ; 

for  (int  wheel  =0;  i  <  4;  ++i) 

vehicle_->applyEngineForce(controller_->f_engine_,  i) ; 

for  (int  wheel  =0;  i  <  2;  ++i) 

vehicle_->setSteeringValue(controller_->steering_,  i) ; 

} 

Listado  4.8:  Implementación  de  algunos  de  los  métodos  mas  importantes  de  la  clase  Car 


enum  class  Direction  {right,  left}; 
class  CarController  { 


float 

f_max_engine_ ; 

float 

acceleration_ ; 

float 

deceleration_ ; 

float 

f_max_braking_ ; 

float 

steering_increment_ ; 

float 

steering_clamp_ ; 

std: : vector<Ogre: :SceneNode*>  wheels_nodes_ ; 


public : 

const  int  rightindex  =  0; 

const  int  upindex  =  1; 

const  int  forwardindex  =  2; 
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float 

mass- ; 

float 

gvehicle_steering_ ; 

float 

wheel_radius_; 

float 

wheel-width- ; 

float 

suspension_stiffness_ ; 

float 

wheel_f riction_; 

float 

suspension_dainping_ ; 

float 

suspension_coinpression_ ; 

float 

roll_influence_ 

float 

connection_height_ ; 

const  btVectorS  car_diinensions_  =  btVector3{l,  0.5f,  2); 
const  btScalar  suspension_rest_length_  =  btScalar(0.5) ; 
const  btVectorS  wheel_direction_cs0_  =  btVector3(0, -1,0) ; 
const  btVector3  wheel_axle_cs_  =  btVector3{-l,0,O) ; 

bool  inverted- ; 

typedef  std i : shared_ptr<CarController>  shared; 
int  nitro_; 

float  f_engine_,  f_braking_,  steering_; 
bool  accelerating_ ,  braking_,  turning_; 

CarController( ) ; 
virtual  -'CarControllerí ) ; 

void  realize(  std: :vector<Ogre: :SceneNode*>  wheels_nodes) ; 

void  accelerate( ) ; 
void  stop_accelerating ( ) ; 

void  brake{ ) ; 
void  stop-braking ( ) ; 

void  turn(  Direction  direction); 
void  stop_turning( ) ; 

void  control-speedO ; 

virtual  void  update(  float  delta!) ; 

void  use_nitro( ) ; 

}: 


Listado  4.9:  Declaración  de  la  clase  CarController 


void 

CarController:  :load_paraineters(std:  :string  file)  { 
Parser  parser; 

std::string  pattern  =  R" (\w*\s* : \s* ( - ?\b\d* . \d*) ) " ; 
parser. inject(pattern) ; 

parser. open(file) ; 

Parser: :Results  parameters  =  parser. get_results( ) ; 
int  Índex  =  0; 
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f_max_engine_ 

st 

acceleration_ 

= 

st 

deceleration_ 

= 

st 

f_max_braking_ 

= 

st 

steering_inc remen t_ 

= 

st 

steering_clamp_ 

= 

st 

mass_ 

= 

st 

gvehicle_steering_ 

= 

st 

wheel_radius_ 

= 

st 

wheel_width_ 

= 

st 

suspension_stiffness_ 

= 

st 

wheel_f riction_ 

= 

st 

suspension_damping_ 

= 

st 

suspension_compression_ 

= 

st 

roll_influence_ 

= 

st 

connection_height_ 

= 

st 

} 

void 

CarController: :accelerate()  { 
if(f_engine_  >=  f_max_engine_) 
accelerating_  =  false; 
return; 

} 

f_engine_  +=  acceleration_; 
accelerating_  =  true; 

} 

void 

CarController: : stop_accelerating ( ) 
accelerating_  =  false; 
f_braking_  =  deceleration_; 

} 

Listado  4.10:  Implementación 
CarController 


r_ to_f loa t (paramete rs [index++] [ 1] 
r_ to_f loa t {paramete rs [index++] [ 1] 
r_ to_f loa t {paramete rs [index++] [ 1] 
r_ to_f loa t {paramete rs [index++] [ 1] 
r_ to_f loa t {paramete rs [index++] [ 1] 
r_ to_f loa t {paramete rs [index++] [ 1] 
r_ to_f loa t {paramete rs [index++] [1] 
r_ to_f loa t (paramete rs [index++] [ 1] 
r_ to_f loa t {paramete rs [index++] [ 1] 
r_ to_f loa t (paramete rs [index++] [ 1] 
r_ to_f loa t {paramete rs [index++] [1] 
r_ to_f loa t (paramete rs [index++] [ 1] 
r_ to_f loa t {paramete rs [index++] [ 1] 
r_ to_f loa t {paramete rs [index++] [ 1] 
r_ to_f loa t {paramete rs [index++] [ 1] 
r_ to_f loa t {paramete rs [index++] [ 1] 


{ 


{ 


de  algunos  de  los  métodos 


) 

) 

) 

) 

) 

) 

) 

) 

) 

) 

) 

) 

) 

) 

) 

) 


mas  importantes  de  la  clase 


En  cuanto  a  la  clase  CarController,  en  los  listados  4.10  y4.9  se  muestran  los  métodos  mas 
importantes: 

■  en  el  método  load_parameters(std:  :string  file)  se  lee  un  fichero  de  configuración 
que  contiene  los  valores  de  las  variables  que  mas  afectan  a  la  movilidad  del  coche.  Un 
ejemplo  del  contenido  de  dicho  fichero  se  puede  ver  en  el  listado  4.11.  Sacando  a  un 
fichero  de  texto  los  valores  de  los  parámetros  de  configuración  del  coche  se  evita  tener 
que  compilar  el  proyecto  cada  vez  que  se  cambia  alguno  de  esos  valores.  Dado  que 
una  configuración  podrá  ser  válida  o  inválida  dependiendo  de  los  deseos  del  equipo 
de  desarrollo,  en  este  caso  la  búsqueda  de  la  configuración  correcta  se  debe  hacer 
mediante  prueba  y  error.  Hay  que  tener  en  cuenta  que  el  tiempo  de  compilación  de 
este  proyecto  ronda  el  minuto,  de  forma  que  con  este  mecanismo  se  ahorra  una  gran 
cantidad  de  tiempo. 

■  Por  otra  parte,  en  esta  clase  se  implementan  las  clases  que  modelan  el  movimiento 
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del  vehículo,  la  forma  en  que  este  acelera  y  frena,  etcétera.  Se  ha  creado  una  serie  de 
métodos  «gemelos»:  unos  que  se  ejecutan  cuando  se  detecta  una  pulsación  de  una  tecla 
y  otros,  cuyo  nombre  comienza  en  stop_,  cuando  se  detecta  la  liberación  de  la  misma. 

Para  el  ejemplo  que  se  está  mostrando  aquí,  el  método  accelerate  se  ejecutará  cuando 
se  detecte  la  pulsación  de  la  tecla  w,  mientras  que  el  método  stop_accelerate  cuando 
se  libere  dicha  tecla.  La  asociación  de  teclas-acción  se  realiza  en  la  clase  HumanCont  ro¬ 
llen,  que  se  mencionará  en  la  sección  4.8.2. 

El  flujo  de  ejecución  de  las  acciones  del  coche  es  el  siguiente: 

■  La  clase  Car  recibe  una  invocación  al  método  exec( )  con  una  acción  determinada  pa¬ 
sada  por  argumento. 

■  Dicho  método  invoca  al  apropiado  de  la  clase  Ca  r,  que  a  su  vez  invocará  al  de  la  clase 
CarContnoller. 

La  clase  CarContnoller  permite  desacoplar  la  lógica  de  control  de  la  clase  Car,  de  forma 
que  podría  haber  diversos  tipos  de  controladores  para  el  coche. 

Explicado  el  proceso  de  inicialización  y  configuración  del  cocheq,  sólo  queda  mostrar 
las  operaciones  básicas  de  la  clase  btVehicleRaycaster.  La  interfaz  que  ofrece  Bullet  para 
controlar  un  vehículo  es  la  siguiente: 

■  void  btRaycastVehicle: :applyEngineForce(  btScalar  forcé,  int  wheel ):  aplica  par  mo¬ 
tor  a  la  rueda  con  ese  índice.  Los  valores  están  expresados  en  N.m. 

■  void  btRaycastVehicle: : setBrake(  btScalar  brake,  int  wheelindex) :  aplica  frenado 
a  la  ruedas  con  ese  índice. 

■  void  btRaycastVehicle: : setSteeringValue  (btScalar  steering,  int  wheel ):  gira  la  rue¬ 
da  con  ese  índice  los  grados  que  indica  el  primer  argumento,  expresados  en  radianes. 


f_max_engine_  :  5000.0 
wheel_radius_  :  0.5 
acceleration_  :  500.0 

wheel_width_  :  0.5 
deceleration_  :  200.0 
suspension_stif f ness_  :  200.0 
f_max_braking_  :  400.0 
wheel_f rictiori-  :  10000.0 
steering_increment_  :  0.05 
suspension_damping_  :  2.0 
steering_clamp_  :  0.25 

suspension_compression_  :  0.1 
rnass-  :  900.0 
roll_influence_  :  1.0 
gvehicle_steering_  :  0.0 
connection_height_  :  0.8 

Listado  4.11:  Lichero  de  configuración  del  coche 
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Car  Physics 


Figura  4.8:  Resultado  de  la  iteración  4.  Modelado  mas  realista  del  movimiento  del  coche  y 
primera  aproximación  a  creación  de  circuitos. 

4.5  Iteración  5:  Creación  de  la  máquina  de  estados  y  de  las  principa¬ 
les  interfaces 

En  esta  iteración  se  pretende  crear  las  primeras  interfaces  gráficas  que  permitan  la  interac¬ 
ción  del  jugador  con  el  videojuego.  El  objetivo  que  se  persigue  en  construir  unas  interfaces 
lo  mas  sencillas  posible,  sobre  las  que  se  pueda  ir  añadiendo  mas  elementos  a  lo  largo  del 
desarrollo. 

Además,  se  intentará  controlar  el  flujo  de  ejecución  del  videojuego  a  través  de  la  crea¬ 
ción  de  una  Máquina  Finita  de  Estados  (SFM)  que  permita  abstraer  los  detalles  de  mas  bajo 
nivel. 

4.5.1  Análisis 

Como  se  ha  dicho,  uno  de  los  objetivos  de  esta  iteración  consiste  en  crear  una  interfaz 
gráfica  lo  suficientemente  simple  como  para  cubrir  las  necesidades  de  interacción  del  jugador 
con  el  videojuego.  Los  elementos  mínimos  que  se  requieren  para  crear  dicha  interfaz  son: 

■  Una  serie  de  botones  que  permitan  cambiar  entre  las  pantallas  del  videojuego.  Por 
ejemplo,  del  menú  principal  a  la  pantalla  donde  se  inicia  el  juego  o  hacia  la  pantalla 
de  créditos. 

■  Elementos  que  permitan  agrupar  dichos  botones  (subventanas).  Por  ejemplo,  durante 
el  juego,  se  dará  la  opción  al  jugador  de  pausarlo  pulsando  el  botón  Escape,  lo  que 
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hará  que  aparezca  una  pantalla  de  pausa  con  una  serie  de  botones. 

■  Cuadros  de  texto  (text  input)  que  permitan  añadir  información  como  el  nickname  del 
jugador  o  la  información  de  red  para  poder  conectarse  al  servidor  en  la  partida  (IP  del 
servidor  cuando  se  implemente  el  componente  de  red) 

■  Checkboxes;  por  ejemplo,  para  activar  o  silenciar  la  música  del  juego. 

■  Barras  de  progreso. 

Por  otra  parte,  se  hace  necesario  implementar  un  mecanismo  de  alto  nivel  que  permita 
cambiar  entre  diferentes  pantallas  del  videojuego.  Cada  una  de  estas  pantallas  tendrá  infor¬ 
mación  que  será  única  de  ellas,  con  condiciones  específicas  para  cambiar  de  una  a  otra  y 
siempre  dependiendo  de  que  se  cumplan  dichas  condiciones;  por  ejemplo,  para  cambiar  de 
la  pantalla  del  menú  a  la  de  juego  es  necesario  que  el  jugador  pulse  el  botón  Jugar.  Del  mis¬ 
mo  modo,  no  se  puede  cambiar  desde  la  pantalla  de  juego  hacia  la  de  menú  sin  pasar  por  la 
pantalla  de  Pausa  y  para  esto  el  jugador  debe  pulsar  el  botón  Escape.  Por  tanto,  parece  claro 
que  se  puede  modelar  el  flujo  de  ejecución  del  videojuego  como  una  SFM. 

Al  implementar  los  cambios  de  estados  del  juego  mediante  una  maquina  de  estados  se 
persigue  desacoplar  la  lógica  del  bucle  de  juego.  El  bucle  de  juego  es  la  estructura  de  control 
principal  de  todo  videojuego  desde  la  que  se  ejecutan  todas  las  demás  instrucciones.  En  el 
listado  4.12  se  puede  ver  el  pseudocódigo  de  un  bucle  de  juego  típico  en  el  que  no  se  hace 
uso  de  una  máquina  de  estados  para  controlar  el  flujo  de  ejecución: 


Mientras  ! game . shutdown : 

CapturarEventosEntrada( ) 

delta!  +=  get_delta_time( ) 

Si  Pantalla  ==  Menú 

(Lógica  de  la  pantalla  Menú) 

Si  Pantalla  ==  Juego 

(Lógica  de  la  pantalla  Juego) 

Si  Pantalla  ==  Pausa 

(Lógica  de  la  pantalla  Pausa) 

Si  Pantalla  ==  Resultados 

(Lógica  de  la  pantalla  Resultados) 

//etcetera 

Rende riza rEscena ( ) 

Eistado  4.12:  Pseudocódigo  del  bucle  de  juego  sin  orientación  a  estados 

Acoplar  la  lógica  específica  de  cada  estado  al  bucle  de  juego  hace  que  este  no  sea  mante- 
nible  ni  flexible,  ya  que  se  generan  numerosos  problemas  al  querer  modificar  dicha  estructu¬ 
ra: 


■  difícil  lectura  y  comprensión  del  codigo  fuente, 

■  mayor  complejidad  a  la  hora  de  realizar  modificaciones. 
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■  aumento  del  número  de  horas  de  desarrollo  en  siguientes  iteraeiones, 

■  mayor  difieultad  a  la  hora  de  depuraeión, 

■  eteétera. 

De  esta  forma,  se  identifiean  dos  problemas  a  los  que  se  ha  dado  solueión  en  esta  itera- 
eión: 

■  Eneontrar  una  biblioteea  de  widget  gráfieos  que  ayude  a  implementar  las  interfaees. 

■  Implementar  un  meeanismo  de  alto  nivel  que  ayude  a  desaeoplar  la  lógiea  de  eambio 
de  pantallas  del  bucle  de  juego. 


4.5.2  Diseño  e  Implementación 

A  partir  del  análisis  inicial  se  dió  paso  a  la  implementación  de  la  máquina  de  estados  y  de 
las  primeras  interfaces. 


Creación  de  las  primeras  interfaces 

A  la  hora  de  seleccionar  una  biblioteca  de  widgets  gráficos  se  ha  elegido  CEGUI  [cegb]. 
CEGUI  es  una  biblioteca  orientada  a  objetos  distribuida  bajo  licencia  MIT.  Está  escrita  en 
C++.  Ofrece  soporte  para  Windows,  Einux  y  MacOS. 

Ea  razón  de  la  elección  radica  en  dos  razones.  Por  un  lado,  CEGUI  cubre  todas  las  nece¬ 
sidades  expuestas  anteriormente:  da  soporte  para  creación  de  ventanas,  botones,  text-inputs, 
checkboxes,  progress  bar,  etcétera.  Por  otro,  CEGUI  fue  la  biblioteca  de  widgets  elegida  por 
el  proyecto  OgreSD  para  crear  las  interfaces  de  los  ejemplos  que  usa  para  mostrar  las  carac¬ 
terísticas  de  que  dispone  el  motor  de  renderizado.  CEGUI  ha  demostrado  ser  la  opción  mas 
completa  a  la  hora  de  gestionar  widgets  gráficos  de  todas  las  alternativas  de  software  libre 
que  se  han  expuesto. 


Eigura  4.9:  Resultado  de  la  iteración  5.  A  la  izquierda  se  ve  una  captura  del  menú  principal, 
a  la  derecha  una  captura  del  menú  de  pausa 
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Se  ha  creado  una  clase  que  hace  mas  sencillo  trabajar  con  CEGUI,  así  como  crear  Overlays 
de  OgreSD,  cuyo  nombre  es  GUI.  Un  Overlay  es  un  elemento  2D  que  se  utiliza  a  la  hora  de 
crear  elementos  decorativos  en  la  interfaz,  como  iconos,  imágenes  de  fondo  e  incluso  barras 
de  vida  y  elementos  similares.  Esta  clase  se  trata  de  un  wrapper  de  CEGUI  y  OgreSD,  mas 
sencillo  de  usar  que  las  bibliotecas  originales. 

En  la  figura  4.9  se  puede  observar  el  resultado  de  esta  primera  parte  de  la  iteración.  Se  ha 
creado  una  ventana  que  cuenta  con  dos  botones,  uno  para  salir  de  la  partida  y  otro  para  iniciar 
el  juego,  y  otra  ventana  para  pausarlo.  A  continuación  se  va  a  exponer  el  proceso  de  creación 
de  la  ventana  del  menú  principal,  ya  que  el  proceso  es  similar  para  cualquier  otra. 

A  la  hora  de  añadir  una  ventana  al  menú  del  juego,  se  crea  un  script  con  extensión  .layout. 
En  el  listado  4.13  se  puede  ver  el  código  correspondiente  al  menú  principal.  Ea  estructura  del 
fichero  es  la  típica  de  un  fichero  XML.  Cada  elemento  cuenta  con  una  serie  de  propiedades, 
tales  como  la  orientación  vertical  u  horizontal,  el  tamaño,  la  tipografía,  el  texto,  la  posición, 
el  tamaño  del  elemento,  etcétera.  En  este  fichero  se  define  un  contenedor,  que  contendrá 
todos  los  elementos  de  la  ventana.  Como  hijos  de  él  se  crean  un  elemento  de  tipo  Texto  y 
dos  botones,  uno  con  el  texto  Play  y  otro  con  Exit. 


<?xml  version=" 1 . 0"  encoding="UTF-8"?> 

<GUILayout  version="4"> 

<Window  name="Menu"  type="TaharezLook/MenuContainer"> 
<Property  name="VerticalAlignment"  value="Centre"  /> 
<Property  name="HorizontalAlignment"  value="Centre"  /> 
<Property  name="AlwaysOnTop"  value="True"  /> 

<Property  name="Size"  value="{{0. 4,0}, {0.3,0}}"  /> 

<Window  name="Title"  type="TaharezLook/Text"> 

<Property  name="VerticalAlignment"  value="Top"  /> 
<Property  name="HorizontalAlignment"  value="Centre"  /> 
<Property  name="Size"  value="{{0. 5,0}, {0.30,0}}"  /> 
<Property  name="Position"  value="{{0. 04,0}, {0,0}}"  /> 
<Property  name="Font"  value="SoulFlission-40"  /> 
<Property  name="Text"  value="Tinman"  /> 

</Window> 

<Window  name="Play"  type="TaharezLook/MenuItem"> 
<Property  name="ID"  value="l"  /> 

<Property  name="VerticalAlignment"  value="Centre"  /> 
<Property  name="HorizontalAlignment"  value="Centre"  /> 
<Property  name="Size"  value="{{0.3,  0.1}, {0.1,  0}}"  /> 
<Property  name="Position"  value="{{0, 0} , {-0 . 1, 100}}"  /> 
<Property  name="Font"  value="Manila-12"  /> 

<Property  name="Text"  value="Play"  /> 

</Window> 

<Window  name="Exit"  type="TaharezLook/Menultem"> 
<Property  name="ID"  value="l"  /> 

<Property  name="VerticalAlignment"  value="Bottom"  /> 
<Property  name="HorizontalAlignment"  value="Centre"  /> 
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<Property  name="Size"  value="{{0.3,  0.1}, {0.1,  0}}"  /> 
<Property  name="Font"  value="Manila-12"  /> 

<Property  name="Text"  value="Exit"  /> 

</Window> 

</Window> 

</GUILayout> 


Listado  4.13:  Definición  de  una  ventana  usando  CEGUI 


Tras  esto  se  debe  crear  un  script  que  defina  el  tipo  de  letra  (SoulMission-40).  En  el  lista¬ 
do  4. 14  se  puede  observar  la  forma  de  definir  una  fuente  de  letra  en  CEGUI. 


<?xml  version="1.0"  ?> 

<Font  version="3"  name="SoulMission-40"  filename="SoulFlission . ttf " 

type="FreeType"  size="40"  nativeHorzRes=" 1280"  nativeVertRes="720"  autoScaled="vertical"/> 

Eistado  4.14:  Definición  de  una  tipografía  en  CEGUI 


Hecho  esto,  falta  inicializar  CEGUI  y  configurar  algunos  aspectos  que  no  están  reflejados 
en  los  Scripts  mostrados.  Para  inicializar  CEGUI  hay  que  ejecutar  la  siguiente  instrucción 
CEGUI: :OgreRenderer: :bootstrapSystem().  CEGUI  permite  operar  con  diversos  motores  de 
renderizado(Irrlicht3D,  Ogre3D)  o  bibliotecas  gráficas  (OpenGE  o  DirectX).  Ea  instrucción 
anterior  inicializa  la  implementación  de  CEGUI  que  aporta  soporte  para  interaccionar  con 
Ogre3D. 

Una  vez  que  está  inicializado  el  componente  principal  de  CEGUI,  el  siguiente  paso  consis¬ 
te  en  inicializar  los  gestores  de  recursos  por  defecto.  Estos  gestores  se  encargarán  de  cargar  y 
gestionar  los  principales  Scripts  de  CEGUI.  En  el  listado  4.15  se  muestra  el  código  necesario 
para  inicializar  los  gestores  por  defecto. 


CEGUI : : Scheme : : setDefaultResourceGroup( "Schemes" ) ; 

CEGUI : : ImageManager: : setImagesetDefaultResourceGroup( "Imagesets" ) ; 

CEGUI: :Font: : setDefaultResourceGroup ( "Fonts" ) ; 

CEGUI : :WindowManager: : setDefauItResourceGroup( "Layouts" ) ; 

CEGUI : :WidgetLookManager: : setDefaultResourceGroup( "LookNFeel" ) ; 

Eistado  4.15:  Iniciafiz, ación  de  los  gestores  de  recursos  por  defecto  de  CEGUI 


Eo  siguiente  es  cargar  el  fichero  que  define  las  ventana  que  se  van  a  mostrar  y  en  confi¬ 
gurarla  como  la  ventana  pricipal.  En  el  listado  4.16  se  muestran  las  sentencias  que  realizan 
estas  acciones. 


std::string  file_name  =  ' 'Menú . layout ' ' 

CEGUI : :Window*  window  =  game_->gui->Ioad_Iayout (file_name) ; 
game_->gui_->get_context( ) . setRootWindow(window) ; 


Eistado  4.16:  Configuración  de  la  ventana  principal 
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Una  vez  que  se  ha  cargado  y  configurado  la  ventana  principal,  se  tiene  que  definir  los 
callbacks  que  serán  ejecutados  cuando  los  botones  de  dicha  ventana  sean  pulsados.  El  código 
que  asocia  las  funciones  de  retrollamada  con  un  botón  se  puede  ver  en  el  listado  4.17.  En 
dicho  listado  se  muestra  el  botón  de  salir  del  juego  del  menú  principal,  al  que  se  asocia  como 
callback  la  función  que  cierra  el  juego. 


std::string  file_name  =  ' 'Menú . layout ' ' 

CEGUI :  :Window*  window  =  game_->gui->load_layout(file_nairie) ; 
window->getChild{ ' ' Exit ' ' ) ->subscribeEvent (CEGUI : : PushButton : : EventClicked , 

CEGUI:  ¡Event:  : Subscriber(&Gairie :  :shutdown,  game_) ) ; 

Eistado  4.17:  Mapeo  de  un  botón  de  la  interfaz  con  un  callback 

En  el  listado  4.17  se  accede  al  elemento  “Exit”  de  la  ventana  definida  en  el  fichero  Me- 
nu.layout(\er  listado  4.13).  A  este  elemento  se  le  suscribe  un  evento  de  tipo  pulsación.  Cuan¬ 
do  se  produzca  un  evento  de  este  tipo(es  decir,  cuando  se  pulse  el  botón),  se  ejecutará  la  fun¬ 
ción  Game; ;  shutdown( ),  de  la  instancia  game_.  CEGUI  implementa  sus  propios  adaptadores  a 
función,  mecanismo  similar  al  que  facilita  la  biblioteca  estándar  de  C-t-i-l  1 

El  último  paso  consiste  en  injectar  el  delta  de  tiempo  trascurrido  desde  la  última  vez  que 
se  renderizó  el  juego.  En  el  listado  4.18  se  pueden  ver  las  instrucciones  necesarias. 


float  delta; 

game_->gui_ ->inject_delta( delta) ; 

Eistado  4.18:  Injección  del  pulso  de  tiempo  a  CEGUI 

El  resultado  de  este  proceso  se  puede  observar  en  la  rama  guiPhysics  de  este  repositorio: 
https  ://goo .  gl/q6]3co. 


Definición  e  implementación  de  la  SFM 

Para  la  creación  de  la  SFM,  se  asocia  cada  estado  con  cada  una  de  las  ventanas  que  apare¬ 
cerán.  En  total,  se  pueden  definir  un  total  de  4  estados  para  esta  iteración:  Menú,  Jugar,  Pausa 
y  Resultados.  En  la  figura  4.10  se  define  la  SFM  correspondiente  a  esta  iteración.  El  estado 
inicial  es  Menú.  Este  estado  no  guarda  información,  simplemente  sirve  como  puente  entre  el 
estado  Jugar  y  el  estado  Salir.  Al  pulsar  el  botón  Salir  se  realiza  una  salida  controlada  del 
videojuego,  liberando  los  recursos  adquiridos.  Al  pulsar  el  botón  Play  se  cambia  al  estado 
Jugar.  Este  estado  guarda  información  acerca  de  la  partida:  el  estado  de  los  jugadores  y  de 
sus  coches.  Desde  el  estado  Jugar  se  puede  ir  al  estado  Pausa  al  pulsar  la  tecla  Escape.  El 
estado  de  pausa  detiene  la  simulación  física,  de  modo  que  el  estado  del  mundo  se  congela 
hasta  que  se  vuelve  al  estado  Jugar.  Desde  el  estado  Jugar  también  se  puede  ir  al  estado  de 
Resultados.  En  este  estado  se  muestran  los  resultados  de  la  carrera. 
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En  la  figura  4.1 1  se  puede  ver  un  diagrama  de  la  estructura  de  las  clases  de  los  estados.  Se 
ha  definido  una  jerarquía  de  herencia;  de  esta  forma,  se  puede  trabajar  con  una  representa¬ 
ción  abstracta  de  la  clase  estado,  y  después  implementar  las  particularidades  de  cada  estado 
por  separado.  Esta  modificación  permite  solucionar  el  segundo  problema.  Se  plantea  una 
modificación  a  la  estructura  de  la  clase  Game  que  existía  hasta  este  momento.  Hasta  ahora, 
se  acoplaba  la  lógica  específica  de  cada  estado  al  bucle  de  eventos. 

Con  la  implementación  de  la  jerarquía  de  estados,  la  nueva  estructura  del  bucle  de  eventos 
se  puede  ver  en  el  listado  4.19,  que  se  puede  encontrar  en  el  fichero  game.cpp.  Al  invocar  el 
método  start,  se  inicia  el  proceso  de  configuración  de  la  clase  Game.  Este  proceso  se  reduce 
a  crear  punteros  inteligentes  de  cada  uno  de  los  estados  y  añadirlos  a  un  mapa.  Ea  clave  de 
cada  entrada  del  mapa  es  una  cadena  de  texto  con  el  nombre  del  estado  correspondiente. 
Tras  esto,  se  invoca  al  bucle  de  juego,  que  se  ejecutará  hasta  que  se  cumpla  la  condición 
de  finalización  del  juego.  El  bucle  de  juego  arranca  el  timer  y  en  cada  iteración  del  bucle 
se  actualiza  el  delta  de  tiempo,  se  capturan  los  eventos  de  entrada  generados  por  el  usuario 
y  se  comprueba  si  el  intervalo  de  tiempo  desde  la  última  vez  que  se  renderizó  la  escena  es 
mayor  que  uno  entre  el  número  de  frames  por  segundo  que  se  quiere  alcanzar  como  máximo. 
Con  esto  se  trata  de  renderizar  una  única  vez  la  escena  por  cada  intervalo.  Por  ejemplo,  si 
se  quiere  renderizar  a  un  ratio  de  60  frames/segundo,  se  calcula  que  el  delta  se  igual  a  1/60 
segundos  (16.6ms)  y  se  renderiza  una  vez  la  escena.  De  esta  forma  nunca  se  renderizarán 
mas  de  60  veces  por  segundo,  ahorrando  recursos  de  la  máquina. 

Si  se  cumple  la  tasa  de  rendizado  por  segundo,  se  comprueba  si  alguno  de  los  eventos 
de  entrada  que  haya  generado  el  usuario,  a  través  del  teclado  o  del  ratón,  tenga  una  acción 
asociada  y,  de  ser  así,  se  ejecutaría.  Después  se  ejecuta  el  método  update( )  del  estado  actual. 
Por  último,  se  renderiza  la  escena  y  se  actualiza  el  valor  de  la  variable  delta  a  cero. 


83 


Figura  4.1 1:  Jerarquía  de  estados 


Cada  estado  tiene  su  propia  lógiea  eonereta  de  modo  que  si  se  quiere  modifiear  ésta  estará 
loealizada  en  la  elase  que  represente  el  estado  en  euestión. 

void 

Game: : start ( )  { 

state_table_ [ "menú" ]  =  std : :make_shared<Menu>(shared_f rom_this ( ) ) ; 
state_table_ [ "pause" ]  =  std : : make_shared<Pause>( shared_f rom_this ( ) ) ; 
state_table_ [ "play" ]  =  std : :make_shared<Play>(shared_f rom_this ( ) ) ; 
state_table_  [ "  results"  ]  =  std : :  inake_shared<Results>(shared_f  rom_this  ( ) ) ; 

set_current_state( "menú" ) ; 

game_loop( ) ; 

} 

void 

Game: :game_loop{ )  { 
timer_ .  start  ( ) ; 
while( !exit_)  { 

delta_  +=  timer_.get_delta_time() ; 
input_->capture( ) ; 
if (delta.  >=  (1/FPS))  { 
input_->check_events{ ) ; 
state_table_[current_state_] ->update( ) ; 
scene_->render_one_f rame( ) ; 
delta.  =  O.f; 

} 

} 

} 


Listado  4.19:  Pseudoeódigo  del  huele  de  juego  haeiendo  uso  de  estados 
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4.6  Iteración  6:  Creación  del  circuito 

Esta  iteración  busca  solucionar  el  problema  relativo  a  la  creación  de  circuitos  para  el  juego. 
Para  facilitar  la  labor  de  diseño,  se  crearán  circuitos  muy  parecidos  a  los  existentes  en  el  juego 
original,  Super  OffRoad.  Se  pretende  crear  circuitos  de  una  forma  lo  mas  sencilla  posible, 
tratando  de  reducir  al  mínimo  el  trabajo  de  modelado  al  tiempo  que  se  hace  mas  simple  la 
adición  de  nuevos  circuitos  en  un  futuro. 

4.6.1  Análisis 

El  objetivo  que  se  persigue  en  esta  iteración  es  el  de  crear  circuitos  sobre  los  que  disputar 
las  carreras  del  juego.  Dado  que  se  pretende  crear  un  clon  del  juego  Super  ojfRoad,  la  estética 
de  los  circuitos  de  este  videojuego  estarán  inspirados  en  los  de  aquél.  En  la  figura  4.12  se 
muestra  uno  de  los  circuitos  originales  de  dicho  juego. 


Eigura  4.12:  Uno  de  los  circuitos  del  clásico  arcade  de  carreras  Super  OffRoad^ 

Por  lo  tanto,  el  primer  paso  consiste  en  analizar  en  detalle  los  circuitos  originales.  Estos 
se  caracterizan  por  tener  distintos  tipos  de  terreno:  rampas  ascendentes  y  descendentes,  ba¬ 
denes,  con  charcos,  bacheados,  etcétera.  Además,  si  se  observan  detenidamente  se  puede  ver 
cómo  en  realidad  estos  circuitos  no  dejan  de  ser  una  sucesión  de  los  mencionados  segmentos 
de  terreno,  dispuestos  en  una  rejilla  de  5x5.  Debido  a  que  el  juego  original  tenía  que  lidiar 
con  unos  recursos  hardware  muy  limitados,  quedaba  descartado  utilizar  gráficos  tridimen¬ 
sionales,  de  forma  que  los  creadores  tuvieron  que  simular  los  saltos,  las  subidas  y  bajadas  de 
los  coches  jugando  con  la  perspectiva.  Por  otra  parte,  los  circuitos  no  son  regulares  debido  a 
que  tenían  que  caber  en  las  reducidas  resoluciones  de  pantalla  existentes  en  la  época^,  razón 
por  la  que  es  complicado  ver  que  en  realidad  son  piezas  similares  puestas  en  sucesión. 

A  la  hora  de  crear  los  circuitos  entra  en  juego  lo  que  se  conoce  como  modelado  3D. 
Básicamente,  este  proceso  consiste  en  moldear  a  un  cuerpo  convexo  hasta  que  se  alcanza  la 

^http  ://i . ytimg . com/vi/3vXfvHD0f qQ/maxresdefault . j  pg 

®La  fecha  de  lanzamiento  del  juego  Super  OjfRoad  fue  en  1989 


85 


forma  deseada.  Este  es  un  proceso  lento  y  costoso,  que  requiere  de  una  larga  experiencia  para 
obtener  un  resultado  de  una  mínima  calidad.  Por  tanto,  se  ha  de  intentar  reducir  al  mínimo  el 
coste  de  este  trabajo.  Normalmente  en  la  creación  de  videojuegos,  los  escenarios  se  crean  en 
un  programa  de  creación  de  gráficos  3D,  en  el  caso  de  este  proyecto  Blender.  En  un  primer 
lugar  se  crean  los  elementos  individuales  que  conformarán  el  escenario,  para  después  ser 
colocados  de  forma  que  se  crea  la  escena  deseada,  que  será  exportada  a  un  formato  con  el 
que  el  motor  de  renderizado  usado  por  el  videojuego  pueda  trabajar. 

Crear  un  formato  textual  para  representar  los  circuitos  formados  por  segmentos  tiene  como 
ventaja  que  es  mas  sencillo  añadir  nuevos,  ya  que  todo  se  reduce  a  crear  un  nuevo  fichero. 

4.6.2  Diseño  e  Implementación 

A  la  hora  de  crear  los  segmentos  que  formarán  el  circuito,  se  han  tenido  en  cuenta  una 
serie  de  consideraciones: 

■  En  primer  lugar,  tienen  que  ser  complementamente  simétricos,  bien  por  la  mitad  en  el 
caso  de  las  rectas  o  por  la  diagonal  en  el  caso  de  las  curvas.  Esto  es  asi  debido  a  que  a 
la  hora  de  rotarlos  si  no  son  simétricos  no  encajan  bien  unos  con  otros. 

■  Aunque  los  segmentos  cuentan  con  una  valla,  ésta  no  es  lo  suficientemente  alta  como 
para  evitar  que  los  vehículos  la  salten.  Para  eliminar  este  problema  se  ha  tenido  que 
añadir  una  pared  transparente  que  haga  de  barrera.  En  el  juego  original  no  existía  este 
problema  debido  a  que  era  un  juego  en  2D,  y  el  motor  de  físicas  no  podía  modelar 
saltos. 

Siguiendo  estas  pautas,  se  han  modelado  los  segmentos  del  circuito  usando  Blender.  En  la 
figura  4.13  se  muestra  una  captura  de  pantalla  de  Blender  mostrando  algunas  de  las  piezas 
que  se  han  modelado.  En  total  se  han  creado  inicialmente  4  modelos:  uno  para  las  rectas, 
otro  para  la  meta,  que  se  diferencia  del  anterior  en  que  tiene  una  raya  a  cuadros  en  la  mitad 
indicando  la  línea  de  salida,  otro  para  las  curvas,  de  los  cuales  se  exportaron  cuatro,  corres¬ 
pondientes  a  cada  uno  de  los  cuadrantes  circulares  y  otro  para  las  rampas,  que  permitirán  a 
los  coches  dar  saltos,  lo  que  añade  algo  de  dinamismo  (no  aparece  en  la  figura  debido  a  que 
es  muy  parecido  estéticamente  a  la  recta). 

Una  vez  modelados  los  segmentos^,  el  siguiente  paso  consiste  en  codificar  los  circuitos  de 
tal  forma  que  se  puedan  representar  en  un  fichero  de  texto.  Para  ello  se  decidió  utilizar  una 
serie  de  caracteres  Unicode,  que  representan  los  diferentes  tipos  de  segmentos.  Combinando 
los  caracteres  en  diferentes  combinaciones  se  pueden  crear  circuitos  de  una  forma  muy  visual 
y  rápida.  Esto  facilita  la  creación  de  circuitos  especiales  para  crear  tests  específicos,  ya  que 
crear  un  nuevo  circuito  es  muy  sencillo.  En  la  figura  4.14  se  puede  ver  un  listado  de  los 
caracteres  usados,  junto  con  un  ejemplo  de  circuito. 

^se  puede  ver  el  proceso  de  creación  de  una  curva  en  https  ://goo .  gl/exFdSL 
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Figura  4.13:  Modelado  de  los  segmentos  que  formarán  los  eireuitos 


Una  vez  estableeida  la  estruetura  del  fichero  de  definición  de  circuitos,  el  siguiente  paso 
consiste  en  crear  una  clase  para  encapsular  la  funcionalidad  relacionada  con  la  creación 
de  circuitos.  Para  ello,  se  ha  creado  la  clase  Track,  cuya  declaración  se  puede  ver  en  el 
listado  4.20  y  la  implementación  de  los  métodos  mas  relevantes  en  4. 21. Esta  clase  representa 
un  circuito,  el  cuál  está  formado  por  un  vector  de  secciones.  Cada  uno  de  las  variables  que 
la  forman  son: 

■  Type:  El  tipo  de  sección.  Esta  información  será  usada  posteriormente  por  el  algoritmo 
de  inteligencia  artificial. 

■  node:  Un  nodo  de  Ogre,  que  será  usado  para  renderizar  ese  segmento  de  circuito. 

■  physic_entity:  Una  entidad  que  guarda  la  malla  3D  de  la  Sección. 

■  body:  Un  cuerpo  físico,  que  gracias  a  las  clases  btBvhTriangleMeshShape  y  MeshStri- 
der,  tendrá  la  misma  forma  geométrica  que  la  malla  3D  usada  por  Ogre,  lo  que  permite 
que  el  coche  interaccione  con  un  gran  realismo.  Ea  primera  clase  crea  una  forma  de 
colisión  estática  creada  con  mallas  triangulares.  Ea  segunda  es  una  clase  que  coge  la 
geometría  de  la  malla  de  la  entidad  de  Ogre3D  con  la  intención  de  crear  la  forma  de 
colisión  anterior. 

■  position:  Ea  posición  en  coordenadas  globales  del  segmento. 

■  id  Un  identificador. 

struct  Section  { 

enum  Type{Meta,  Rectl,  Rect2,  RightCurvel, 

RightCurve2,  LeftCurvel,  LeftCurve2}; 

Type  type; 

Ogre: :SceneNode*  node; 

Ogre: :Entity*  physics_entity; 

btRigidBody*  body; 
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\u2500  rect-h 
\u2502  rect-v 
\u257E  ramp-h 
\u257F  ramp-v 
\u2570  curv-R-1 
\u256D  curv-R-2 
\u256F  curv-L-1 
\u256E  curv-L-2 
\u2505  finish 


Figura  4.14:  Ejemplo  de  fichero  de  definición  circuito  con  el  circuito  que  se  crea  a  partir  de 
él 


btVectorB  position; 
int  id; 

}; 


class  Track  { 

std::string  file_name_; 
std: iwifstream 

std:  :map<wchar_t,  std :  : function<Section ( )»  builder_; 
std: :map<wchar_t,  std : : pair<char,  char»  directions_; 
std: :map<char,  char>  ends_; 

int  x_,  z_,  index_; 

Scene: :shared  scene_; 

Physics : : shared  physics_; 

wchar_t  current_char_; 

std: : vector<Ogre: :SceneNode*>  stairs_; 

public : 

typedef  std: :shared_ptr<Track>  shared; 
std : : vector<Section>  segments_; 
int  columns_; 

Track(std: :string  file); 

void  next(std: :string  file); 

void  next(Scene: :shared  scene,  Physics :: shared  physics); 
Section  create_section(std: :string  ñame); 

void  reseto ; 

}; 
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Listado  4.20:  Declaración  de  la  clase  Track 


Track: :Track( std :: st ring  file)  { 

file_name_  =  file;  x_  =  columns-  =  0;  z_  =  -60; 


builder_[u'\u2500'] 

= 

std : 

:bind(&Track: 

:  create_section , 

this , 

" rectl"); 

builder_[u'\u2502'] 

= 

std : 

:bind(&Track: 

:  create_section , 

this , 

" rect2"): 

builder_[u'\u256D'] 

= 

std : 

:bind(&Track: 

:  create_section , 

this , 

"curve- right2 

builder_[u'\u2570'] 

= 

std : 

:bind(&Track: 

:  create_section , 

this , 

"curve- rightl 

builder_[u'\u256E'] 

= 

std : 

:bind(&Track: 

:  create_section , 

this , 

"curve-left2" 

builder_[u'\u256F'] 

= 

std : 

:bind{&Track: 

:  create_section , 

this , 

"curve-leftl" 

builder_[u'\u257E'] 

= 

std : 

:bind{&Track: 

:  create_section , 

this , 

" rampl" ) ; 

builder_[u'\u257F'] 

= 

std : 

:bind{&Track: 

:  create_section , 

this , 

" ramp2"): 

builder_[u'\u2505'] 

= 

std : 

:bind{&Track: 

:  create_section , 

this , 

"meta" ) ; 

void 

Track: :open_file{std: :string  file)  { 
file_ .open(file) ; 
file_.imbue(std: :locale("") ) ; 

std::cout  «  "open  file:  "  «  file  «  std::endl; 
if  ( ! file_ . is_open ( ) )  { 
std::cerr  «  "no  file:  \n" 

«  file 
«  std : : endl ; 

exit(-l) ; 

} 

} 

void 

Track: :next(std: :string  file)  { 
index_  =  0; 
open_file{file) ; 

std : : wstring  line; 
while(getline(file_,  line))  { 
for(auto  circuit_seginent :  line){ 
if  (builder_  [circuit_seginent] )  { 
current_char_  =  circuit_seginent; 
segments_ . push_back(builder_ [circuit_segment] ( ) ) ; 

} 

x_  +=  20; 
index_++; 

} 

z_  +=  20; 

columns_  =  x_  /  20; 
x_  =  0; 

} 

z_  =  -60; 
file_ . close( ) ; 
order_track( ) ; 

} 

void 

Track:  :order_track( )  { 


89 


auto  meta  =  std: :find_if (seginents_.begin() ,  segments- . end ( ) ,  [&](auto  segment){ 
return  segment . type  ==  Section: :Type: :Meta; 

}); 

int  id  =  meta->id; 

ineta->id  =  0; 

char  direction  =  '\0'; 

int  last_id  =  id; 

char  last_direction  =  'L'; 

for(int  Índex  =  1;  Índex  <  segments_ . size( ) ;  index++)  { 

direction  =  get_direction(segments_[id] .type,  segments_[last_id] .type,  last_direction) ; 
last_direction  =  direction; 
last_id  =  id; 

id  =  get_next_section(id,  direction); 
segments_ [id] . id  =  índex; 

} 

std : : sort (segmentS- . begin ( ) ,  segmentS- . end ( ) ,  [&]{auto  segmentl,  auto  segment2){ 
return  segmentl. id  <  segment2.id; 

}): 

} 

void 

Track: : reset( )  { 

for(auto  section:  segments_)  { 

scene_->destroy_node( section . node) ; 
scene_->dest roy_entit y (section . physics_entity) ; 
physics_->remove_rigid_body (section . body) ; 

delete  section. body->getCollisionShape() ; 
delete  section . body; 

} 

segments_ . clear( ) ; 

for(auto  node:  stairs_) 

scene_->destroy_node(node) ; 

} 

Listado  4.21:  Implementación  de  algunos  de  los  métodos  mas  importantes  de  la  clase  Track 


El  algoritmo  de  creación  del  circuito  se  puede  ver  en  el  listado  4.21,  en  el  método  next  ( ) . 

A  pesar  de  su  sencillez,  cabe  destacar  un  par  de  aspectos  del  listado  anterior: 

■  En  primer  lugar  se  abre  el  fichero  del  circuito  utilizando  el  método  open_file(file). 
Debido  a  que  se  está  trabajando  con  caracteres  Unicode,  es  necesario  especificar  la 
codificación  que  se  va  a  utilizar.  En  el  caso  de  este  proyecto,  se  usan  los  locales  de 
C.  Esto  usando  el  método  imbue( )  de  la  clase  de  la  clase  ifstream,  que  se  encarga  de 
encapsular  las  operaciones  relacionadas  con  la  lectura  de  ficheros. 

■  En  el  constructor  de  Track  se  inicializa  un  mapa  que  relaciona  caractéres  Unicode  con 
callbacks  al  método  create_section  ( ) .  Dicha  función  crea  el  cuerpo  gráfico  y  el  físico 
de  la  sección  haciendo  uso  de  la  clase  Scene,  que  es  el  wrapper  de  OgreSD,  y  de  la 
clase  Physics,  que  es  el  wrapper  de  Bullet  Physics^. 

^ambas  clases  han  sido  implementadas  en  este  proyecto 
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■  Dentro  del  while  se  reeorre  el  fiehero  línea  por  línea  y  dentro  del  for  se  reeorre  cada 
línea  carácter  por  carácter.  Por  cada  carácter,  se  crea  una  nueva  sección  en  la  posición 
que  le  corresponda.  Para  ello,  existen  dos  variables  que  sirven  como  desplazamiento 
en  el  eje  X  y  Z,  que  se  incrementan  de  20  en  20,  pues  esa  es  el  tamaño  de  los  segmentos 
(20  unidades  de  largo  y  20  de  ancho). 

■  Cada  uno  de  los  segmentos  se  almacenan  en  el  vector  segments_,  para  poder  acceder  a 
ellos  mas  adelante. 

■  Tras  terminar  de  crear  los  segmentos  del  circuito  todavía  queda  un  último  paso  por 
hacer,  ordenar  el  buffer  segments-  para  que  se  pueda  acceder  a  los  segmentos  en  orden. 
Es  decir,  el  orden  deseable  es  comenzando  desde  la  meta,  siguiendo  la  orientación  de 
los  segmentos,  hasta  llegar  al  segmento  anterior  a  esta. 

Esto  mismo  es  lo  que  hace  el  método  order_track( ):  busca  el  segmento  de  tipo  Me¬ 
ta  dentro  del  buffer.  En  este  momento  se  usará  la  variable  id  para  ordenar  en  orden 
ascendente  el  vector.  Por  tanto,  se  le  asigna  el  id  0  al  segmento  Meta  y,  suponiendo 
que  el  sentido  del  circuito  es  hacia  la  izquierda,  se  recorren  cada  uno  de  los  siguientes 
segmentos  hasta  llegar  al  final,  asignándoles  un  valor  creciente  a  la  variable  id  de  cada 
uno  de  ellos. 

■  Por  último,  se  usa  el  algoritmo  sort  de  la  biblioteca  estándar  para  ordenar  los  segmen¬ 
tos  en  orden  creciente  atendiendo  al  valor  del  atributo  id. 

El  resultado  de  esta  iteración  se  puede  observar  en  la  figura  4.15.  El  circuito  que  se  muestra 
en  la  figura  4. 14  corresponde  a  la  fase  final  del  proyecto. 


Eigura  4.15:  Resultado  de  la  iteración  7.  Primer  circuito  creado 
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4.7  Iteración  7:  Adición  de  mecánicas  de  juego  y  mejora  visual  del 
videojuego 

En  esta  iteración  se  pretende  mejorar  el  aspecto  visual  del  videojuego  añadiendo  sombras 
dinámicas,  efectos  de  partículas  como  humo  para  el  coche,  etcétera.  Por  otra  parte,  se  añaden 
elementos  que  contribuyan  a  enriquecer  la  experiencia  de  juego,  como  son  los  powerups. 
Estos  elementos  ofrecen  ventajas  a  los  jugadores,  lo  que  hacen  mas  interesante  las  partidas, 
al  fomentar  la  competición  por  intentar  coger  dichos  objetos. 

4.7.1  Análisis 

En  este  punto  del  desarrollo  ya  se  ha  conseguido  tener  una  base  sobre  la  que  comenzar  a 
construir  el  videojuego.  En  esta  iteración  se  darán  los  primeros  pasos  para  mejorar  el  aspecto 
visual  y  añadir  algunas  mecánicas  de  juego. 

A  la  hora  de  seleccionar  las  mecánicas  de  juego,  hay  una  gran  variedad.  Para  seguir  con  la 
forma  en  que  se  está  desarrollando  el  proyecto,  se  ha  decidido  imitar  las  mecánicas  usadas  en 
el  juego  Super  OjfRoad.  En  ese  juego  se  repartían  por  todo  el  circuito  a  lo  largo  de  la  carrera 
unas  bolsas  de  dinero  y  botellas  de  Oxido  nitroso,  a  intervalos  regulares  de  tiempo.  Eas  bolsas 
de  dinero  daban  dinero  al  jugador,  que  podía  ser  usado  al  acabar  la  carrera  para  comprar 
mejoras  del  coche.  El  jugador  también  conseguía  dinero  dependiendo  de  la  posición  en  la 
que  acabase  la  carrera.  En  cuanto  a  la  botella  de  nitro,  se  acumulaban  y  al  ser  usadas  aportaba 
una  mejora  de  velocidad  al  jugador.  En  esta  iteración  se  ha  decidido  crear  una  botella  de  nitro 
y  una  bolsa  de  dinero,  así  como  los  mecanismos  necesarios  para  modificar  los  atributos  del 
jugador  cuando  su  coche  recoja  alguno  de  estos  elementos  al  ir  por  el  circuito. 

En  segundo  lugar,  se  han  añadido  partículas  que  simulan  el  humo  del  tubo  de  escape 
del  vehículo,  además  de  otras  que  aparecen  al  recoger  los  powerups.  Por  otra  parte,  para 
mejorar  el  acabado  visual  de  un  juego  en  3D,  un  aspecto  fundamental  son  las  sombras.  Estas 
dan  profundidad  a  la  escena,  dando  al  jugador  la  sensación  de  esa  tercera  dimensión.  Esto 
mejora  drásticamente  la  experiencia  ya  que  la  sensación  de  inmersión  es  mucho  mayor  al 
aportar  mayor  realismo. 

Existe  una  técnica  conocida  como  mapeado  de  sombras  precalculadas.  Esta  técnica  itera 
sobre  los  focos  de  luz  y  calcula  las  sombras  que  proyectarían  cada  uno  de  los  objetos  de  la 
escena.  Típicamente,  se  aplican  las  sombras  sobre  las  propias  texturas  de  los  objetos  de  la 
escena,  de  forma  que  en  realidad  consiste  en  modificar  la  textura  de  la  malla  para  aparentar 
que  se  están  aplicando  sombras.  Para  poder  llevarse  a  cabo,  es  necesario  utilizar  un  programa 
de  generación  de  gráficos  3D,  aplicar  dicha  técnica  y  exportar  la  malla  y  las  texturas  genera¬ 
das  como  resultado.  Una  vez  que  se  cargasen  los  modelos  con  las  sombras  precalculadas,  no 
es  necesario  generar  sombras  sobre  estos  objetos. 

Por  supesto,  hay  que  tener  en  cuenta  que  debido  a  que  las  sombras  están  calculadas  di¬ 
rectamente  sobre  las  texturas,  esta  técnica  no  se  puede  aplicar  sobre  escenarios  dinámicos. 
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Debido  a  la  forma  en  que  se  crean  los  circuitos  en  este  proyecto,  no  es  interesante  usarla  ya 
que  eso  haría  que  hubiese  que  generar  los  circuitos  directamente  sobre  blender,  ya  que  hay 
que  generar  las  sombras  de  la  escena  completa.  Esto  haría  que  se  perdiese  la  ventaja  obtenida 
en  iteraciones  anteriores,  en  las  que  se  consiguió  que  la  generación  de  circuitos  sea  genérica 
y  completamente  transparente.  Por  esta  razón  se  deben  usar  sombras  dinámicas. 

4.7.2  Diseño  e  Implementación 

El  proceso  de  creación  de  los  powerups  se  puede  resumir  en  los  siguientes  pasos: 

■  Modelado  de  las  mallas  y  creación  de  animaciones.  Usando  blender,  se  crean  las  mallas 
3D,  tanto  de  la  bolsa  como  de  la  botella  de  nitro,  que  se  pueden  ver  en  la  figura  4.16. 
Blender  permite  la  exportación  de  animaciones  basadas  en  un  formato  compatible  con 
OgreSD  a  través  de  un  plugin. 


Eigura  4.16:  Modelado  de  powerups 

■  Hecho  esto  se  hace  necesario  una  forma  de  gestionar  las  animaciones  que  se  ejecutarán 
a  lo  largo  del  desarrollo  del  juego.  Para  ello  se  crea  un  gestor  de  animaciones  Este 
gestor  encapsula  las  operaciones  de  OgreSD,  aportando  una  forma  sencilla  que  per¬ 
mitir  que  se  ejecute  un  callback  cuando  la  animación  se  acabe,  o  simplemente  seguir 
ejecutando  la  animación  en  bucle  si  fuese  necesario. 

■  A  continuación  hay  que  añadir  el  soporte  para  la  detección  de  colisiones.  Se  debe 
poder  gestionar  las  colisiones  entre  los  coches  y  los  powerups,  de  forma  que  surge 
la  necesidad  de  expandir  la  funcionalidad  del  gestión  de  físicas.  En  el  listado  4.22 
se  puede  ver  el  código  que  detecta  y  ejecuta  los  callbacks  asociados  a  las  colisiones. 
A  grandes  rasgos,  se  crea  un  mapa  en  el  que  se  registran  pares  de  cuerpos  físicos  y 
se  asocian  a  un  callback.  En  el  listado  4.23  se  puede  ver  código  fuente  que  registra 

^ver  en  https  ://goo.gl/Rlxsgr 
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un  par  de  colisión  y  su  callback.  Durante  la  ejecución  del  bucle  de  juego  se  invocará 
la  función  Physics ; ;  check_collision  ( ) .  Esta  función  se  fundamenta  sobre  el  segundo 
paso  del  pipeline  de  dinámica  de  físicas  (ver  la  figura  3.4).  Se  recorren  los  pares  de 
colisión,  formados  por  cuerpos  físicos,  que  calcula  Bullet  y  se  itera  sobre  ellos  para 
ver  si  alguno  de  esos  cuerpos  coincide  con  los  registrados  en  el  mapa  mencionado. 
Si  de  entre  todos  los  pares  de  colisión  detectados  por  Bullet,  alguno  coincide  con  los 
registrados  en  el  mapa  creado,  se  ejecutará  la  función  asociada.  De  esta  forma,  se 
consigue  gestionar  las  colisiones  de  una  forma  flexible  y  dejando  la  lógica  de  gestión 
de  colisiones  totalmente  desacoplada  de  la  lógica  principal  del  juego. 

■  Por  último  se  debe  lanzar  una  serie  de  partículas  al  detectar  la  colisión.  En  este  caso, 
se  añadió  una  función  al  gestor  de  escena.  Eas  partículas  en  Ogre  se  caracterizan  por 
tener  un  fichero  de  configuración  que  define  un  «shader».  Mediante  la  utilización  de 
una  imagen,  el  fichero  de  configuración  define  la  cantidad  de  partículas,  la  velocidad 
de  emisión,  el  color  de  las  partículas,  la  dirección  local  en  que  se  emitirán,  etcétera. 


void 

Physics :: check-collision ( )  { 

int  contact_point_caches  =  dynamics_world_->getDispatcher( ) ->getNuiriManifolds { ) ; 

for  (int  i=0;i  <  contact_point_caches ; i++)  { 
btPersistentManifold*  contact_cache  = 

dynamics_world_->getDispatcher( ) ->getManifoldByIndexInternal (i) ; 

const  btCollisionObject*  object_a  =  contact_cache->getBody0( ) ; 
const  btCollisionObject*  object_b  =  contact_cache->getBodyl( ) ; 

if (triggers_[Physics: :CollisionPair{object_a,  object_b}])  { 
triggers_ [Physics : : CollisionPair{object_a,  obj ect_b}] { ) ; 

} 

else  if  (triggers_[Physics: :CollisionPair{object_b,  object_a}])  { 
triggers_ [Physics : : CollisionPair{object_b,  obj ect_a}] { ) ; 

} 

} 

} 

} 


Eistado  4.22:  Gestión  de  colisiones  en  la  clase  de  gestión  de  físicas 


physics_->add_collision_hooks ( {  nit ro_->body_ ,  player->get_car( ) ->chassis_body_} , 

std: :bind(&Player: :pick_nitro,  playee. get( ) ,  nitro_)); 

Eistado  4.23:  Registro  de  un  par  de  colisión 


Una  vez  creados  los  powerups,  el  siguiente  paso  consiste  en  seleccionar  la  técnica  de  som¬ 
breado  utilizado.  Se  utilizará  una  técnica  llamada  Stencil  Shadows.  El  funcionamiento  básico 
consiste  en  calcular  el  volumen  de  las  sombras  resultantes  al  aplicar  la  luz  existente  en  la  es¬ 
cena  a  los  cuerpos  que  la  componen  y  luego  extruyendo  el  volumen  sobre  las  superficie  a  la 
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que  se  apliea  la  sombra.  La  ventaja  de  esta  téenica  es  que  permite  erear  sombras  muy  ajusta¬ 
das  a  la  forma  geométrica  del  cuerpo  que  las  proyecta.  Esta  técnica  tiene  el  contrapunto  de 
que  el  coste  computacional  depende  del  número  de  polígonos  de  los  emisores  de  sombras;  sin 
embargo,  si  se  reduce  el  número  de  polígonos  cualquier  tipo  de  hardware  puede  ejecutarla, 
por  reducidas  que  sean  las  prestanciones  de  éste.  Dado  que  se  ha  tenido  cuidado  al  modelar 
cada  uno  de  las  mallas  utilizadas  en  este  proyecto,  ya  que  se  ha  minimizado  el  número  de  po¬ 
lígonos.  Esto  ha  hecho  que  sea  mas  complicado  de  modelar,  pero  permite  reducir  la  exigencia 
de  recursos  hardware,  lo  que  hace  que  esta  técnica  de  sombreado  se  ajusta  perfectamente  a 
este  proyecto,  consiguiendo  sombras  realistas  a  un  bajo  coste  computacional. 


Eigura  4.17:  Resultado  de  la  iteración  8.  A  la  izquierda  se  puede  observar  las  partículas  de 
humo  añadidas  al  vehículo.  A  la  derecha,  las  sombras  dinámicas  aplicadas  al  circuito  y  los 
coches 


4.8  Iteración  8:  Implementación  del  modelo  de  red 

En  esta  iteración  se  procederá  a  realizar  una  implementación  del  modelo  de  red  del  juego. 
Se  estudiarán  los  diferentes  modelos  de  red  existentes  en  videojuegos,  a  fin  de  escoger  el  que 
mejor  se  adapte  a  las  características  de  este  proyecto.  Por  otra  parte,  se  priorizará  alcanzar 
una  correcta  jugabilidad  en  LAN,  implementando  los  mecanismos  en  red  necesarios. 

4.8.1  Análisis 

En  la  sección  3.6  se  introducían  los  conceptos  de  consistencia  e  inmediatez.  En  dicha 
sección  se  definía  la  inmediatez  como  el  tiempo  que  le  lleva  al  juego  representar  las  acciones 
del  jugador. 

El  videojuego  que  se  trata  de  desarrollar  necesita  minimizar  el  tiempo  de  respuesta,  ya 
que  un  juego  de  carreras  se  caracteriza  por  tener  movimientos  rápidos,  de  forma  que  los 
jugadores  esperan  poder  controlar  el  coche  de  una  forma  fluida.  Por  tanto,  se  hace  necesario 
escoger  un  modelo  de  red  que  permita  maximizar  la  inmediatez. 

No  existe  mucha  literatura  que  clasifique  los  diferentes  modelos  de  red.  En  la  sección  3.7 
se  mostraba  una  clasificación  creada  por  Glenn  Fiedler.  En  esta  sección  se  intentará  mostrar 
bajo  qué  circunstancias  es  mejor  usar  un  modelo  u  otro: 
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■  Determistic  Lockstep  [Fiel4a]:  es  apropiado  en  situaciones  donde  el  motor  de  físicas 
es  totalmente  determinista,  o  la  simulación  física  no  es  un  problema.  Se  caracteriza 
por  sincronizar  el  juego  usando  únicamente  las  acciones  de  cada  uno  de  los  jugador 
de  la  partida,  delegando  al  motor  de  físicas  la  labor  de  sincronización.  Cada  jugador 
envía  las  acciones  que  ha  realizado  y  espera  recibir  las  acciones  de  los  demás  jugado¬ 
res.  La  ventaja  de  esta  aproximación  es  que  el  ancho  de  banda  consumido  es  mínimo 
e  independiente  del  número  de  objetos  físicos  que  haya  en  la  escena,  ya  que  toda  la 
información  que  se  envía  y  se  recibe  son  las  acciones  de  cada  uno  de  los  demás  juga¬ 
dores. 

■  Basados  en  interpolación  [Fiel4b] :  modelo  que  históricamente  se  ha  usado  en  situacio¬ 
nes  donde,  por  motivos  de  recursos,  no  se  quería  utilizar  motor  de  físicas  en  el  cliente. 
Se  caracteriza  por  enviar  la  información  mas  importante  cada  frame  (snapshots)  e  ir 
almacenando  en  un  bufer  dichos  resúmenes  del  estado  global  del  juego  para  poder  in¬ 
terpolar  el  estado  local  de  la  partida  del  cliente.  Es  apropiado  cuando  el  número  de 
jugadores  aumenta  por  encima  de  4,  ya  que  permite  una  sincronización  mucho  mas 
precisa  que  la  que  se  consigue  con  el  método  anterior. 

■  State  Synchronization:  al  contrario  que  el  modelo  anterior,  en  este  se  envía  el  estado 
de  los  objetos  físicos  mas  importantes  de  la  escena  a  una  tasa  lo  mas  alta  posible.  En 
este  modelo  se  hace  uso  del  motor  de  físicas  pero  no  se  confía  plenamente  en  él  (como 
se  hacía  en  el  primer  método),  sino  que  se  envía  algunos  datos  clave  que  permiten 
sincronizar  las  diversas  instancias  de  juego.  Se  usa  un  modelo  de  prioridades  para 
determinar  cuál  de  los  objetos  del  juego  tiene  una  mayor  necesidad  de  sincronización. 

Cada  una  de  las  técnicas  de  sincronización  anteriores  tienen  ventajas  e  inconvenientes  que 
los  hacen  mas  apropiados  dependiendo  de  las  circunstancas  de  cada  proyecto: 

■  El  modelo  basado  en  interpolación  tiene  el  inconveniente  de  que  no  es  trivial  interpo¬ 
lar  el  movimiento  de  un  vehículo  de  una  forma  fiel  al  movimiento  real.  Debido  a  las 
propiedades  físicas  del  movimiento  de  un  vehículo,  el  movimiento  normal  del  mismo 
en  un  terreno  lleno  de  baches,  como  es  el  caso  de  los  circuitos  que  se  han  modelado, 
consiste  en  oscilaciones  del  chasis  en  vertical  y  permanentes  saltos,  así  como  cam¬ 
bios  bruscos  de  dirección.  En  otros  tipos  de  juegos  tan  exigentes  como  pueden  ser  los 
EPS,  en  donde  los  cambios  de  dirección  también  son  habituales,  la  simulación  física 
es  mucho  mas  sencilla  debido  a  que  la  forma  en  que  tenemos  de  andar  las  personas 
normalmente  no  implica  variaciones  de  altura;  es  decir,  el  movimiento  del  personaje 
puede  ser  simulado  perfectamente  en  un  plano  2D  y  añadir  una  animación  puramente 
estética.  Por  otra  parte,  debido  a  la  gran  cantidad  de  información  necesaria  para  poder 
interpolar  correctamente  el  estado  de  la  escena  (el  modelo  está  pensado  para  ser  usa¬ 
do  en  situaciones  donde  no  se  ejecuta  el  motor  de  físicas  en  el  cliente)  se  tiene  que 
comprimir  los  datos  para  reducir  el  ancho  de  banda. 
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■  Debido  a  que  la  simulación  física  es  tan  compleja,  no  tiene  sentido  utilizar  el  modelo 
deterministic  lockstep,  ya  que  en  poco  tiempo  se  desincronizaría. 

■  Por  tanto,  de  lo  anterior  se  deduce  que  el  modelo  que  mejor  se  adapta  a  las  necesidades 
es  el  método  State  synchwnization. 

Además,  hay  que  tener  en  cuenta  todos  los  problemas  de  asincronismo  derivados  de  las  co¬ 
municaciones  en  red.  El  videojuego  tiene  que  ser  capaz  de  gestionar  la  recepción  de  paquetes 
de  forma  asincrona,  de  forma  que  no  se  bloquee.  Para  ello  habrá  que  hacer  uso  de  técnicas  de 
programación  concurrente,  como  son  hilos  y  monitores,  que  servirán  para  realizar  un  acceso 
concurrente  a  los  buffers  donde  se  almacenaran  los  mensajes  antes  de  ser  gestionados,  que 
evite  que  se  bloquee  el  hilo  principal  de  procesamiento. 

4.8.2  Diseño  e  Implementación 

A  la  hora  de  implementar  el  modelo  de  red,  el  primer  paso  consiste  en  escoger  la  tecno¬ 
logía  que  dará  soporte  al  proyecto.  Las  grandes  compañías  de  desarrollo  de  software  tienen 
suficiente  personal  como  para  implementar  su  propio  motor  de  red  utilizando  sockets.  Los 
sockets  ofrecen  una  gran  flexibilidad  y  potencia,  pero  debido  a  que  son  mecanismos  de  tan 
bajo  nivel,  tienen  el  inconveniente  de  obligar  al  desarrollador  a  tener  que  implementar  to¬ 
das  las  características  de  alto  nivel  que  requiera  como:  codificación  eficiente  de  los  datos, 
compresión  automática  de  datos, ...  Por  ello  se  ha  elegido  utilizar  ZeroC  Ice. 

A  continuación  se  irán  explicando  los  detalles  de  cada  uno  de  los  componentes  que  forman 
el  modelo  de  red  de  este  juego.  Se  comenzará  con  los  tipos  de  datos  usados  y  el  API  que 
usarán  el  cliente  y  el  servidor.  Se  seguirá  explicando  los  detalles  del  servidor,  para  finalizar 
con  el  cliente. 


enum  Action  {AccelerateBegin,  AccelerateEnd ,  BrakeBegin,  BrakeEnd, 

TurnRight,  TurnLeft,  TurnEnd,  UseNitro}; 

sequence<Action>  ActionSeq; 

struct  Quaternion  {float  x,  y,  z,  w;  }; 

struct  VectorB  {float  x,  y,  z;  }; 

struct  Carinfo  { 
byte  carid; 
int  seqNumber; 

Quaternion  orientation; 

VectorB  position; 

VectorB  velocity; 

ActionSeq  actions; 

}: 


sequence<CarInfo>  Snapshot; 

struct  Logininfo  { 
byte  carid; 

Ice: :StringSeq  playerNicks; 

}: 
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interface  Peer  { 

void  notifyíSnapshot  valué); 

}; 


interface  AuthoritativeServer  { 
void  notifyíSnapshot  valuey); 

["amd"]  Logininfo  login(string  nickname,  Peer*  proxy); 

["amd"]  void  startRace(string  nickname); 
void  disconnectíbyte  id); 

}; 

Listado  4.24:  Estructuras  de  datos  usados  en  el  modelo  de  red 

En  el  listado  4.24  se  muestran  las  estrueturas  de  datos  que  se  usadas  en  las  eomunieaeiones 
del  juego.  El  tipo  de  datos  mas  importante  es  Snapshot,  que  es  un  eontenedor  de  estrueturas 
Ca ninfo.  Dieha  estruetura  representa  el  estado  de  un  eoehe  y  está  formada  por  un  identifiea- 
dor  del  jugador  (usado  por  el  servidor),  un  número  de  seeueneia  de  mensaje,  la  orientaeión, 
veloeidad  y  posieión  del  eoehe  y  las  aeeiones  realizadas  por  el  eoehe.  En  la  seeeión  4.4.2  se 
expliea  el  tipo  de  aeeiones. 

En  euanto  a  las  interfaees,  el  eliente  implementa  la  interfaz  Peer,  euyo  únieo  método  sirve 
al  servidor  para  enviar  el  estado  del  juego  aetualizado  a  eada  uno  de  los  olientes.  Por  su  parte, 
el  servidor  implementa  la  interfaz  AuthoritativeServer,  que  euenta  eon  un  método  notify( ) 
homólogo  al  anterior,  y  dos  métodos  loginO  y  startRaceO  que  son  usados  por  los  olientes 
para  ooneetarse  al  servidor  e  indioar  que  eomienee  la  earrera,  respeetivamente. 

A  oontinuaeión  se  explioarán  los  detalles  de  implementaeión  del  servidor. 


class  AuthoritativeServeríTinman .AuthoritativeServer) : 
peers  =  [] 
n_players  =  0 
next_race  =  [] 

NUMBER-PLAYERS  =  4 

def  notifyíself,  snapshot,  current): 
for  car_info  in  snapshot: 
sys . stdout . flush ( ) 

self . send_to_other_peers (car_info,  snapshot) 

def  send_to_other_peers(self ,  car_info,  snapshot): 

Índex  =  0 

for  peer  in  self. peers: 

if  Índex  !=  car_info.carId: 

peer [2] .notify(list( snapshot) ) 

Índex  =  índex  +  1 

def  login_async ( self ,  cb,  nickname,  proxy,  current=None) : 
print ( "login :  {0}" . format (nickname) ) 

if([nick  for  nick  in  self. peers  if  nick[l]  ==  nickname]): 
print  "Nickname  {0}  already  registered" 
nickname  =  nickname  +  str(len(self .peers) ) 
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self . peers . append ( (cb,  nickname,  proxy)) 
if  len(self .peers)  ==  self .NUMBER^PLAYERS: 
self . start_game( ) 

def  start_game(self ) : 
id  =  -1 

playersNick  =  [ ] 

for  cb,  nick,  proxy  in  self. peers: 
playe rsNick. append (nick) 

for  cb,  nick,  proxy  in  self. peers: 

print{ "enviando  nick  j ugador{0} . . . " . format (nick) ) 
id  =  id  +  1 

login_info  =  Tinman . LoginInfo(id,  playersNick) 
cb. ice_ response(login_info) 

def  startRace_async(self ,  cb,  nickname,  current=None) : 
self . next_  race. append ( cb) 

if {len(self .next_race)  ==  self . NUMBER_PLAYERS) : 
self . start_new_ race ( ) 

def  start_new_race{self ) : 

for  cb  in  self .next_race: 

cb . ice_ response{ ) 
self .next_race  =  [] 

def  disconnect ( self ,  player_id,  current): 
print  "disconecting  ",  player_id,  "..." 
if  len(self .peers)  ==  1: 
del  self . peers [0] 

return 

del  self .peers[player_id] 

class  Server(Ice. Application) : 
def  run{self ,  argv) : 

broker  =  self . communicator ( ) 
servant  =  AuthoritativeServer( ) 

adapter  =  broker. createObjectAdapter( "AuthoritativeServerAdapter" ) 
proxy  =  adapter. add{servant,  broker. stringToIdentity{ "tinman" ) ) 

print(proxy) 

sys . stdout . flush ( ) 

adapter. activate( ) 

self . shutdownOnInterrupt ( ) 

broker .waitForShutdown ( ) 

return  0 

server  =  Server( ) 

sys . exit (server . main (sys .argv) ) 

Listado  4.25:  Implementación  del  servidor  de  red  del  juego 
El  servidor  está  implementado  en  Python.  La  razón  es  que  al  ser  un  lenguaje  de  prototipado 
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el  desarrollo  se  agilizó  muchísimo,  gracias  a  todas  las  ventajas  que  aporta  python,  como  ser 
un  lenguaje  interpretado  (no  se  compila)  y  tener  un  tipado  dinámico. 

Por  otra  parte,  usar  Python  ayuda  a  ilustrar  la  flexibilidad  que  aporta  usar  ZeroC  Ice  ,  que 
permite  comunicar  distintos  componentes  del  juego,  incluso  aunque  estén  implementados  en 
distintos  lenguajes  de  programación. 

La  clase  Server  hereda  de  Ice.  Application,  clase  abstracta  que  proporciona  ICE  para  crear 
aplicaciones  sencillas.  Dentro  de  la  clase  Server  se  inicializa  el  comunicador,  objeto  que 
gestiona  las  operaciones  de  ICE,  se  crea  un  sirviente  (objeto  de  la  clase  AuthoritativeServe- 
rAdapter)  y  se  registra  al  adaptador  de  objetos.  Tras  esto  se  activa  el  adaptador  y  se  inicia  el 
bucle  principal  de  la  aplicación  usando  el  método  del  comunicador  waitForShutdown  ( ) . 

Una  vez  invocado  ese  método  el  servidor  quedará  a  la  escucha  en  el  puerto  10000  has¬ 
ta  que  se  interrumpa  la  ejecución  (por  ejemplo,  pulsando  Ctrl  +  c).  La  configuración  del 
servidor  se  realiza  mediante  línea  de  órdenes,  pasándole  la  ruta  de  un  fichero  a  tal  efec¬ 
to.  Ejecutando  el  comando  del  listado  4.26  se  arranca  el  servidor  y  en  el  listado  4.27  se 
muestra  el  fichero  de  configuración.  En  dicho  fichero  se  indica  el  nombre  del  adaptador 
(AuthoritativeServerAdapter)  y  una  lista  de  endpoints,  en  los  que  se  le  indica  el  puerto  y  el 
protocolo  que  se  usará  en  dicho  endpoint. 


. /network/server. py  - -Ice . Config=config/server . config 

Eistado  4.26:  Comando  de  ejecución  del  servidor  del  juego 


AuthoritativeServerAdapter. Endpoints=tcp  -p  1OGO0:  udp  -p  10001 

Eistado  4.27:  Eichero  de  configuración  del  servidor  del  juego 

En  este  proyecto  se  usan  dos  protocolos  de  transporte,  dependiendo  del  tipo  de  mensaje 
que  se  quiera  transmitir.  Eas  invocaciones  remotas  al  método  notify,  tanto  de  la  interfaz  Peer 
como  de  AuthoritativeServer  usan  el  protocolo  UDP.  Por  su  parte,  las  invocaciones  realiza¬ 
das  por  los  clientes  a  los  métodos  login( )  y  startRace( ),  y  sus  correspondientes  respuestas 
utilizan  el  protocolo  TCP. 

Ea  razón  de  utilizar  UDP  para  las  invocaciones  que  se  realizan  durante  el  gameplay  es 
que  TCP  no  es  un  protocolo  apropiado  para  juegos  de  acción  rápida.  TCP  es  un  protocolo 
orientado  a  flujo,  el  cuál  trabaja  sobre  IP,  que  es  un  protocolo  que  usa  paquetes,  razón  por  la 
que  debe  romper  el  flujo  de  datos  para  enviarlo  en  paquetes  individuales.  Debido  a  que  TCP 
intenta  reducir  la  sobrecarga  de  la  red,  no  envía  paquetes  mas  pequeños  de  un  determinado 
tamaño  (supongamos  100  bytes).  Esto  es  un  problema  en  juegos  donde  se  necesite  enviar 
datos  lo  mas  rápidamente  posible,  ya  que  se  almacenarán  hasta  que  los  datos  almecenados 
superen  una  determinada  cantidad,  momento  para  el  que  los  datos  pueden  haberse  quedado 
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obsoletos  [Fie08]. 

Volviendo  al  servidor,  en  los  métodos  login  y  startRace  se  utiliza  Asynchronous  Method 
Dispatch  (AMD)(junto  con  su  homólogo  en  el  lado  del  cliente  Asynchronous  Method  Invoca- 
tion  (AMI)).  AMD  es  un  método  de  programación  asincrono  que  permite  al  servidor  atender 
varias  peticiones  simultáneamente.  Sin  embargo,  la  razón  por  la  que  se  usa  es  porque  permite 
a  los  clientes  hacer  login  o  indicar  que  quieren  que  comience  una  nueva  carrera  sin  bloquear 
el  hilo  principal  de  ejecución. 


deni 

OientBroker 

Server 

create 


cbCalIback 


Menu::update() 


c  hange_s  tate(  State : :  Ray ) 


begin  k)gin(cb.  níck.  pcoxy) 


isCornpleleO 


ice_response(playerslnlo 
< - 


logir_async(nick.  proxy) 


playersinfo 


Figura  4.18:  invocación  asincrona  del  cliente  al  servidor(AMl) 

Para  explicar  cómo  se  usa  AMD  o  AMI,  se  mostrará  el  proceso  de  login,  que  está  ilustrado 
en  las  figuras  4.18  y  4.19: 

■  El  cliente  invoca  el  método  begin_login()  (ver  listado  4.29.  Esto  devuelve  un  obje¬ 
to  de  tipo  Ice; ; AsyncResultPtr  que  puede  ser  usado  para  comprobar  el  estado  de  la 
transacción. 

■  El  servidor  recibe  la  invocación,  pero  en  el  método  login_async  ( ) .  Esto  permite  retra¬ 
sar  la  respuesta  de  dicha  invocación  hasta  el  momento  en  el  que  hayan  iniciado  sesión 
un  número  minimo  de  jugadores,  en  este  caso  4  (por  la  variable  number_players).  Di¬ 
cho  método  recibe  tres  argumentos:  un  callback  que  podrá  invocar  para  informar  al 
cliente  que  todos  los  jugadores  se  han  registrado  a  la  partida,  el  nickname  del  jugador 
y  el  proxy  del  objeto  Peer  que  crea  el  cliente,  sin  el  cuál  el  servidor  no  podría  enviarle 
el  estado  de  la  partida,  cuando  esta  comience. 
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Figura  4.19:  despachado  asincrono  de  las  peticiones  del  cliente  por  parte  del  servidor(AMD) 


■  Cuando  el  número  de  jugadores  acordado  se  haya  registrado,  el  servidor  invocará  a 
través  del  método  login_async()  a  start_game( ).  Usando  los  callbacks  (cb)  recibidos 
antes,  el  servidor  responde  a  todos  los  clientes. 


void 

Menú : : update(float  delta)  { 

game_->gui_->inject_delta( delta) ; 
expose_car_->animation(delta) ; 
if(login_  &&  login_->isCompleted{ ) )  { 
complete_login ( ) ; 

} 

} 


Listado  4.28:  Método  update  de  la  clase  Menú 


■  Por  último,  el  método  start_game( )  del  sirviente  AuthoritativeServer  invocará  el  mé¬ 
todo  del  callbackice_response. 

■  El  cliente,  a  través  del  método  isCompleted  ( )  será  notificado  de  que  el  proceso  de  login 
ha  finalizado,  y  cambiará  al  estado  Play,  donde  comenzará  la  carrera. 

Adapten: :Adapter(Car: : shared  car)  { 
try  { 

seq_number_  =  0; 

Socket.  =  {"1",  10000}; 
car_  =  car; 

Ice: :StringSeq  argv{"Tinman"}; 
communicator.  =  Ice: :initialize(argv) ; 

}catch(const  : : Ice : : LocalException&  exception)  { 
std::cerr  «  "No  server  running"  «  std::endl; 

} 

} 
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Ice: : AsyncResultPtr 

Adapten: :login(std: :shared_ptr<Session>  session)  { 
try{ 

if (peer_) 

return  auth_server_->begin_login(session->human_player_->nick_,  peer_) ; 

std : : stringstream  endpoint; 
endpoint  «  "tcp:udp"; 

endpoint . str{ " ") ; 

endpoint  «  "tinman:  tcp  -h  "  «  socket_ . first  «  "  -p  "«  socket_ . second ; 
endpoint  «  ":  udp  -h  "  «  socket_ . first  «  "  -p  "«  socket_ . second  +  1; 
endpoint . str{ ) ; 

ObjectPrx  proxy  =  communicator_->stringToProxy(endpoint . str( ) ) ; 
auth_server_  =  Tinman: : AuthoritativeServerPrx: :checkedCast(proxy) ; 

dg  ram_auth_server_  =  Tinman : : AuthoritativeServerPrx: : uncheckedCast (proxy ->ice_datagram( ) ) ; 

Tinman: :PeerPtr  servant  =  new  Tinman: :PeerI(session) ; 

ObjectAdapterPtr  adapten; 

adapten  =  communicator_->createObjectAdapterWithEndpoints { "PeerAdapter" ,  "tcp:udp"); 

ObjectPrx  peer_proxy  =  adapter->add(servant, 

communicator_->stringToIdentity( "peer-tinman" ) ) ; 


peer_  =  Tinman : : PeerPrx: : uncheckedCast (pee r_proxy->ice_datagram( ) ) ; 
std::cout  «  peer_proxy  «  std::endl; 
adapter->activate( ) ; 

return  auth_server_->begin_login(session->human_player_->nick_,  peer_) ; 
}catch (const  : :IceUtil: :NullHandleException&  exception)  { 
std::cerr  «  "Error:  login  failed!"  «  std::endl; 
return  nullptr; 

} 

catch(const  Ice: :ConnectionRefusedException  exception)  { 
std::cerr  «  "Error:  connection  refused!"  «  std::endl; 
return  nullptr; 

} 

} 

Tinman : : Logininfo 

Adapten: :complete_login(Ice: :AsyncResultPtr  async_result)  { 
login_info_  =  auth_server_->end_login(async_result) ; 
return  login_info_; 

} 

Ice: : AsyncResultPtr 

Adapten: :next_race(std: :string  nickname)  { 

return  auth_server_->begin_startRace(nickname) ; 

} 

Ice: : AsyncResultPtr 

Adapten: :next_race(std: :string  nickname)  { 

return  auth_server_->begin_startRace(nickname) ; 

} 
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void 

Adapter: :notify(Tinman: :Action  action)  { 

Tinman : : VectorB  position{car_->get_position{ ) . getX( ) , 

car_->get_position ( ) . getY( ) ,  car_->get_position ( ) . getZ( ) } ; 

Tinman : : VectorB  velocity{car_->get_velocity{ ) . getX( ) , 

car_->get_velocity ( ) . getY( ) ,  car_->get_velocity ( ) . getZ( ) } ; 

Tinman : :Quaternion  orientation{car_->get_orientation ( ) . getX( ) , 
car_->get_orientation( ) .getY{ ) , 
car_->get_orientation( ) .getZ{ ) , 
car_->get_orientation ( ) . getW{ ) } ; 

Tinman: :CarInfo  car_state; 
car_state. carid  =  login_info_.carId; 
car_state. seqNumber  =  ++seq_number_ ; 
car_state.orientation  =  orientation; 
car_state. position  =  position; 
car_state. velocity  =  velocity; 
car_state.actions  =  Tinman: :ActionSeq{action}; 

Tinman :: Snapshot  snapshot  =  {car_state}; 

dgram_auth_server_->notify{snapshot ) ; 

} 

void 

Adapter: :disconnect( )  { 

std::cout  «  "[Adapter]  "  «  _ fuñe _  «  std::endl; 

dgram_auth_server_->disconnect (login_info_ . carid ) ; 

} 

Listado  4.29:  Implementación  del  módulo  de  red  del  cliente 


Como  se  ve,  aunque  el  proceso  de  invocación  asincrono  en  el  cliente  y  de  despachado 
asincrono  en  el  servidor  es  complejo,  permite  que  no  se  bloquee  la  interfaz  del  cliente  cuando 
realiza  dicha  invocación,  mientras  que  el  despachado  asincrono  permite  al  servidor  recibir 
múltiples  peticiones  simultáneamente. 

Por  último,  hay  que  mencionar  que  se  extendió  la  funcionalidad  del  jugador  creando  una 
clase  asbtracta  llamada  Controller.  Dicha  clase  permite  crear  diferentes  tipos  de  jugado¬ 
res,  descoplando  la  lógica  de  control  del  jugador  de  la  clase  Player.  En  la  fig  5.2  se  puede 
observar  la  jerarquía  de  controladores. 

En  esta  iteración  se  crearon  dos  tipos  de  controladores:  Human  que  representa  al  jugador 
humano  y  Network,  que  representa  a  los  jugadores  remotos.  Se  llama  jugador  local  al  jugador 
humano,  y  en  contrapunto,  jugador  remoto  a  los  jugadores  humanos  que  juegan  en  otros 
ordenadores  dentro  de  la  misma  partida. 

En  los  listados  list: controller,  4.32  y  4.31  se  observan  la  clase  padre  y  la  implementa¬ 
ción  de  las  clases  Human  y  Network  respectivamente. 
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class  Controller  { 

public : 

std: : queue<Tinman : :CarInfo>  updates_; 

Car:  :  shared  car_; 

ControllerObserver: :shared  observer_; 

typedef  std : : shared_ptr<Controller>  shared; 

Controller(Car: : shared  car); 
virtual  -Controllerí ) ; 

virtual  void  configureO  =  0; 
virtual  void  update(float  delta)  =  0; 
virtual  void  exec(Tininan:  :Action  action)  =  0; 

void  disconnectí ) ; 

}; 


Listado  4.30:  Declaración  clase  Controller 


HumanController: :HumanController(EventListener: :shared  listener, 

KeyBinding  key_bindings ,  Car::shared  car):  Controller(car)  { 

input_  =  listener; 
key_bindings_  =  key_bindings ; 
network-iTiode-  =  true; 

} 

void 

HumanController: : configure( )  { 

std::cout  «  "[HumanController]  configure"  «  std::endl; 
for(auto  key_bind:  key_bindings_ )  { 

input_->add_hook({key_bind.first,  EventTrigger: :OnKeyPressed},  EventType: : repeat, 

std : : bind ( (void (HumanController: : *) 

(Tinman: :Action) ) (&HumanController: :exec) ,  this,  key_bind . second . f irst  )); 
input_->add_hook({key_bind.first,  EventTrigger: :OnKeyReleased},  EventType: :dolt0nce, 

std : : bind ( (void (HumanController: : *) 

(Tinman : : Action) ) (&HumanCont rolle r: :exec) ,  this ,  key_bind . second . second) ) ; 

} 

} 

void 

HumanController: : update(float  delta)  { 
car_->update(delta) ; 

} 


void 

HumanController: :exec(Tinman: :Action  action)  { 
car_->exec (action) ; 
if ( netwo  rk_mode_ ) 

observer_->notify(action) ; 

} 


Listado  4.31:  clase  NetworkController 
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NetworkController: : NetworkController(Car: : shared  car):  Controller(car)  { 
duration_  =  last_size_  =  0.f; 
last_num_sequence_  =  -1; 

} 

void 

NetworkController: : configure( )  { 

} 

void 

NetworkController: :exec{Tinman: :Action  action)  { 
car_->exec(action) ; 

} 

void 

NetworkController: : update(float  delta)  { 

for(int  snapshots_per_f rame  =  get_snapshots_per_f rame(delta) ; 
snapshots_per_f rame  !=  0; 
snapshots_per_f rame- - )  { 

if (updates_ . size( )  >  1  && 

updates_ . f ront ( ) . seqNumber  >  last_num_sequence_)  { 

for(auto  action:  updates_.front() .actions) 
car_->exec{action) ; 
car_->synchronize(updates_ . f ront ( ) ) ; 
last_num_sequence_  =  updates_ . f ront (). seqNumber; 
updates- . popí ) ; 

} 

} 

car_->update(delta) ; 

} 

int 

NetworkController: :get_snapshots_per_frame(float  delta)  { 
if (updates_ .empty ( ) )  { 

int  snapshots_initial_case  =  0; 
return  snapshots_initial_case; 

} 

if (updates_ . sizeí )  <=  6)  { 

return  1; 

} 

int  snapshots_per_f rame  =  updates_ . size( )  -  6; 
return  snapshots_per_f rame; 

} 


Listado  4.32:  clase  HumanController 


Tinman :: PeerI :: PeerI (Session :: shared  session)  { 
session_  =  session; 

} 
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void 

Tinman: :PeerI: :notify(const  : iTinman : : Snapshot&  snapshot, 

const  Ice: :Current&  current)  { 
session_->store(snapshot) ; 

} 


Listado  4.33:  clase  PeerI 


void 

Session:  :store(Tininan:  :Snapshot  snapshot)  { 
for(auto  car_info:  snapshot) 

get_player(car_info.carId) ->store(std : :move(car_info) ) ; 

} 

Listado  4.34:  Método  store  de  la  clase  Session 

En  el  método  exec( )  de  la  clase  HumanCont  rollen  se  notifica  al  servidor  el  estado  del  coche 
en  cada  momento.  En  el  método  notify  de  la  clase  Adapten  se  observa  la  construcción  del 
mensaje  que  se  envía  al  servidor  (ver  listado  4.29). 

Por  otra  parte,  el  método  update  de  la  clase  NetworkCont  rollen  se  utiliza  para  sincronizar  el 
estado  de  los  jugadores  remotos  a  partir  de  los  mensajes  recibidos  por  parte  del  servidor.  En 
el  listado  4.33  se  puede  ver  el  código  que  se  ejecuta  cuando  el  cliente  recibe  una  invocación 
del  servidor,  mientras  que  en  el  método  notify  del  servidor  (ver  listado  4.25)  se  observa 
cómo  notifica  de  los  cambios  en  el  estado  del  juego  el  servidor  a  los  demás  clientes. 

Si  se  observa  la  clase  Pee  ni  (listado  4.33)  se  puede  ver  lo  genérico  que  es  el  proceso  de 
notificación.  El  servidor  invoca  el  método  notiy  del  proxy  del  cliente,  el  cliente  recibe  la 
invoca  en  dicho  método  y  se  invoca  el  método  store  de  la  clase  Session,  que  almacena  en 
un  buffer  los  snapshots  recibidos  por  le  servidor  (ver  listado  4.34.  En  dicho  método  se  com¬ 
prueba  a  que  jugador  remoto  va  dirigido  cada  uno  de  los  snapshots  recibidos  y  se  almacena 
en  el  atributo  de  tipo  Adapten  que  almacena  NetworkCont  rollen. 

4.8.3  Análisis  del  ancho  de  banda  consumido 

Se  ha  realizado  una  estimación  del  ancho  de  banda  consumido  por  los  clientes  por  el 
protocolo  de  red  usado  en  este  proyecto.  Esta  estimación  está  basada  en  el  tamaño  de  cada 
mensaje  multiplicado  por  el  número  de  mensajes  enviados  por  segundo. 

El  tamaño  de  cada  mensaje  es  el  siguiente: 

■  Cada  mensaje  contiene  una  estructura  de  tipo  Ca  ninfo. 

■  Cada  estructura  Ca  ninfo  contiene: 

•  un  byte  (1  byte). 

•  un  entero  (4  bytes). 

•  la  posición,  que  es  un  vector  de  tres  íloats  (3*4  bytes). 
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•  la  rotación,  que  es  un  vector  de  cuatro  floats  (4*4  bytes). 

•  la  velocidad,  que  es  un  vector  de  tres  floats  (3*4  bytes). 

•  una  secuencia  de  acciones,  que  típicamente  contiene  una  única  acción.  Dado  que 
el  tipo  de  datos  Action  es  un  enumerado,  típicamente  el  compilador  lo  convierte 
a  tipo  entero  (4  byte). 

Por  otra  parte,  la  cabecera  típica  de  un  mensaje  de  ZeroC  ICE  ocupa  14  bytes 

En  total,  el  tamaño  del  mensaje  es  1  +  4  +  12  +  16  +  12  +  4  =  A%ytes.  Dado  que  el  cliente 
envía  60  mensajes  por  segundo  al  servidor,  el  cliente  consume  un  total  de  60 A  (49  +  14)  = 

3780bytes  /  segundo  =  3,7  Kbytes  /  segundo 

Por  su  parte,  el  servidor  consume  ese  mismo  ancho  de  banda,  pero  multiplicado  por  cada 
jugador,  de  forma  que  para  este  videojuego  consumiría  AjugadoresAS,  7Kbyte/ segundopor  jugador 
14,  SKbytes / segundo 

Por  tanto,  el  ancho  de  banda  total  consumido  por  el  protocolo  del  juego  es  lA, SKbytes / segundo. 


4.9  Iteración  9:  Implementación  de  Bots  mediante  lA 

En  este  nuevo  incremento  del  proyecto  se  persigue  implementar  un  algoritmo  de  inteli¬ 
gencia  artificial  que  permita  que  un  jugador  controlado  por  la  máquina  pueda  dar  una  vuelta 
a  un  circuito,  en  un  tiempo  razonable,  independientemente  de  la  topología  del  mismo.  Por 
otra  parte,  se  debe  permitir  a  la  máquina  esquivar  de  alguna  forma  los  obstáculos  que  se 
interpongan  en  su  camino,  como  otros  coches  que  se  hallen  en  mitad  del  circuito,  las  paredes 
del  mismo,  etcétera. 

4.9.1  Análisis 

A  la  hora  de  implementar  el  algoritmo  de  inteligencia  artificial  para  este  proyecto  hay  una 
serie  de  problemas  que  se  deben  resolver: 

■  se  debe  detectar  obstáculos  dinámicamente 

■  debe  ser  capaz  de  adaptarse  a  diferentes  tipos  de  circuitos. 

Eos  algoritmos  de  inteligencia  artificial  de  los  videojuegos  comerciales  de  carreras  típi¬ 
camente  utilizan  un  algoritmo  A*  para  buscar  la  ruta  óptima  del  circuito,  definiendo  una 
serie  de  waypoints  a  lo  largo  del  circuito  como  espacio  de  búsqueda.  Sin  embargo,  típica¬ 
mente  estos  algoritmos  son  computacionalmente  muy  costosos,  ya  que  buscan  a  lo  largo  de 
todo  el  espacio  de  búsqueda,  llegando  a  definir  cientos  de  waypoints  si  se  trata  de  juegos 
realistas. 

Además,  este  tipo  de  algoritmos  no  tienen  en  cuenta  los  posibles  obstáculos  dinámicos 
que  pueda  haber  a  lo  largo  de  la  carrera,  como  por  ejemplo  los  otros  coches. 

'''información  del  protocolo  de  ICE:  https://cloc.zeroc.com/display/Ice35/Protocol+Messages 
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Para  reducir  la  complejidad  del  algoritmo  de  inteligencia  artificial,  se  decidió  seguir  una 
aproximación  un  tanto  diferente  a  la  del  algoritmo  A*.  Aunque  sí  que  se  define  un  espacio 
de  búsqueda,  siendo  este  los  diferentes  segmentos  que  conforman  el  circuito,  se  ha  decidido 
que  el  vehículo  realice  una  detección  dinámica  de  obstáculos  combinada  con  una  serie  de 
acciones  estáticas  dependiendo  del  tipo  de  segmento  en  el  que  se  encuentre  el  vehículo. 

4.9.2  Diseño  e  Implementación 

Teniendo  en  cuenta  todas  las  consideraciones  anteriores,  se  decidió  diseñar  el  algoritmo 
en  función  de  dos  factores: 

■  si  el  vehículo  tiene  algún  obstáculo  delante  a  una  distancia  suficientemente  cercana, 

■  el  tipo  de  segmento  sobre  el  que  esté  posicionado  en  cada  momento. 

En  el  listado  4.35  se  muestra  la  implementación  de  la  clase  BotCont  rollen,  clase  donde  se 
encapsula  el  algoritmo  que  se  explicará  a  continuación.  Dicha  clase  es  otro  tipo  de  controla¬ 
dor  que  se  ha  creado  para  evitar  acoplar  el  algoritmo  de  lA  a  la  clase  Player. 

Para  detectar  obstáculos  o  colisiones  se  utilizan  dos  métodos.  Por  un  lado,  se  lanzan  rayos 
hacia  delante,  hacia  la  izquierda  y  la  derecha  rotando  el  primer  rayo  -i-15  grados.  Si  el  primer 
rayo  colisiona,  es  un  indicador  de  que  hay  un  obstáculo  delante  del  vehículo,  mientras  que 
si  el  rayo  de  la  derecha  o  el  de  la  izquierda  colisionan  significa  que  el  vehículo  está  cerca  de 
un  muro. 

A  la  hora  de  lanzar  los  rayos  hay  que  tener  en  cuenta  que  los  segmentos  del  circuito  tienen 
pequeñas  oscilaciones  en  el  terreno,  así  como  hay  otros  tipos  de  segmentos  que  son  rampas 
de  una  altura  similar  a  la  del  del  coche.  Para  evitar  que  los  rayos  choquen  contra  objetos 
que  no  son  obstáculos,  hay  que  lanzarlos  unas  unidades  por  encima  del  eje  perpendicular 
del  plano  que  define  el  terreno.  Por  esta  razón,  no  se  pueden  detectar  colisiones  contra  otros 
vehículos  usando  este  método.  Para  ello,  se  ha  tenido  que  hacer  una  asunción:  si  el  vehículo 
está  acelerando  y  la  velocidad  de  este  no  supera  un  valor  mínimo,  significa  que  el  vehículo 
está  atascado. 

Cuando  el  algoritmo  detecta  alguna  de  estas  condiciones,  realiza  la  acción  correspondien¬ 
te: 

■  Si  el  rayo  lanzado  en  la  dirección  en  que  está  orientado  el  vehículo  ha  colisionado,  el 
algoritmo  hará  acelerar  marcha  atrás  hasta  que  el  rayo  deje  de  colisionar. 

■  Si  el  rayo  derecho  o  izquierdo  colisionan,  significa  que  el  vehículo  está  cerca  de  un 
muro  bien  por  la  parte  de  la  derecha  o  de  la  izquierda.  En  este  caso,  el  algoritmo  hará 
que  el  vehículo  gire  en  la  dirección  contraria  a  la  del  rayo  que  está  colisionando. 

■  Si  el  vehículo  está  acelerando  y  la  velocidad  de  éste  no  supera  un  cierto  valor,  signi¬ 
fica  que  este  está  atascado,  de  modo  que  el  algoritmo  hará  que  el  vehículo  acelere  en 
sentido  contrario. 
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Por  otra  parte,  si  el  algoritmo  no  detecta  ningún  obstáculo,  realizará  una  serie  de  acciones 
dependiendo  del  tipo  de  segmento  sobre  el  que  se  halle  el  vehículo: 

■  Si  se  trata  de  una  recta  o  de  la  meta,  acelerará. 

■  Si  se  trata  de  una  curva,  girará  en  el  sentido  de  la  curva. 

A  la  hora  de  girar,  dependiendo  del  sentido  en  que  avance  el  vehículo,  el  giro  puede  ser 
hacia  la  derecha  o  hacia  la  izquierda;  en  otras  palabras,  la  dirección  de  giro  depende  del  tipo 
de  segmento  que  haya  antes  de  la  curva.  Para  facilitar  la  identificación  del  tipo  de  segmento 
se  ha  agrupado  cada  pieza  dependiendo  de  su  malla.  En  la  figura  4.14  se  muestran  todos  los 
tipos  de  segmentos  y  en  el  listado  4.20  se  puede  ver  la  estructura  Section. 

A  grandes  rasgos,  el  algoritmo  detecta  la  dirección  de  giro  a  partir  de  estas  reglas: 

■  Si  el  vehículo  se  halla  en  una  curva  de  tipo  RightCurvel  y  el  segmento  anterior  era 
horizontal,  girará  a  la  derecha.  Si  por  el  contrario  era  un  segmento  vertical,  girará  a 
la  izquierda.  Se  entiende  que  los  segmentos  verticales  son  recta2,  rampa2  o  cualquier 
curva  que  pueda  acoplarse  de  forma  vertical.  De  forma  similar,  se  entiende  la  horizon¬ 
talidad  de  los  tipos  de  segmento. 

■  Si  se  encuentra  en  una  curva  de  tipo  RightCurvel,  el  vehículo  girará  a  la  derecha  si  el 
segmento  anterior  era  vertical  y  hacia  la  izquierda  si  era  un  segmento  horizontal. 

■  Si  el  segmento  actual  es  de  tipo  LeftCurvel  girará  a  la  izquierda  si  el  segmento  anterior 
es  horizontal  y  hacia  la  derecha  si  el  segmento  anterior  es  vertical. 

■  Por  último,  si  se  trata  de  una  curva  de  tipo  LeftCurvel  girará  a  la  izquierda  si  el  seg¬ 
mento  anterior  es  vertical  y  hacia  la  derecha  si  es  horizontal. 

Por  último,  para  que  el  vehículo  pueda  tener  la  información  acerca  del  segmento  de  cir¬ 
cuito  sobre  el  que  se  encuentra  en  cada  momento,  se  hace  uso  de  una  utilidad  creada  espe¬ 
cíficamente  para  este  proyecto.  Aprovechándonos  de  la  información  que  proporciona  Bullet 
en  la  fase  Broadphase  de  su  pipeline  físico,  se  utilizan  los  pares  de  colisión  que  detecta  para 
comprobar  si  alguno  de  ellos  corresponde  con  algún  cuerpo  físico  del  cuál  se  quiera  reali¬ 
zar  alguna  acción  en  el  momento  que  se  detecte  la  colisión.  Para  ello,  se  registra  el  cuerpo 
físico  del  coche  junto  con  cada  uno  de  los  cuerpos  físicos  de  los  segmentos  del  circuito.  En 
el  listado  4.23  se  ve  un  código  similar,  en  el  que  se  registra  una  colisión  entre  el  coche  y 
un  powerup.  Se  delega  la  labor  de  detección  de  colisiones  del  vehículo  a  la  clase  Physics,  la 
cuál  es  un  wrapper  que  encapsula  llamadas  a  Bullet  Physics. 

void 

BotController: :update(float  delta)  { 

btVectorS  position  =  car_->get_position( ) ; 
position . setY(5) ; 

btVectorB  direction  =  car_->get_direction(4) ; 
direction.setY(5) ; 

btVectorB  next_waypoint  =  get_next_waypoint{index_) ; 


lio 


next-waypoint . setY(5) ; 


auto  callback  =  physics_->raytest(position,  direction); 
if  (callback.hasHitO  ) 
correct_position() ; 

else 

go_to_waypoint(next_waypoint) ; 
car_->update(delta) ; 

} 

void 

BotController: :go_to_waypoint(btVector3  next_destination)  { 
exec(Tinman i : AccelerateBegin) ; 

if (car_->current_segment_.type  ==  Section : : Meta  || 
car_->current_segment_.type  ==  Section :: Rect )  { 
exec (Tinman : :TurnEnd) ; 

return; 

} 

if (car_->current_segment_.type  ==  Section: :RightCurve)  { 
exec(Tinman: :TurnRight) ; 

return; 

} 


if (car_->current_segment_.type  ==  Section :: LeftCurve)  { 
exec(Tinman: :TurnLeft) ; 

return; 

} 

} 

btVector3 

BotController: :get_next_waypoint(int  Índex)  { 
return  car_->current_segment_ . position ; 

} 

void 

BotController: : correct_position ( )  { 

btVector3  position  =  car_->get_position() ; 
position. setY(5) ; 

btVector3  direction  =  car_->get_direction(4) ; 
direction. setY(5) ; 

btVector3  right_direction  =  direction. rotate(btVector3(0, 1,0) ,  degree_to_radians(20) ) ; 
btVector3  left_direction  =  direction. rotate(btVector3{G, 1,0) ,  degree_to_radians ( -20) ) ; 
auto  right_ray  =  physics_->raytest(position,  right_direction) ; 
auto  left_ray  =  physics_->raytest(position,  left_direction) ; 

if ( right_ray . hasHit ( )  &&  left_ray.hasHit() )  { 
exec (Tinman : : AccelerateEnd) ; 
car_->exec (Tinman: :BrakeBegin) ; 

} 

if ( right_ray . hasHit ( ) )  { 

exec(Tinman: : AccelerateBegin) ; 
exec(Tinman: :TurnLeft) ; 

return; 
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} 

if (left_ray . hasHit ( ) )  { 

exec (Tinman : : AccelerateBegin) ; 
exec (Tinman : :TurnRight) ; 

return; 

} 

} 

void 

BotController: :exec(Tinman: :Action  action)  { 
car_->exec{action) ; 
observer_->notify (action) ; 


Listado  4.35:  Clase  BotController 


4.10  Iteración  10:  Instrumentación  del  videojuego 

En  esta  iteración  se  va  a  implementar  un  mecanismo  de  instrumentación  que  permita  ge¬ 
nerar  pruebas  que  simulen  comportamientos  típicos  del  jugador  de  forma  programática;  en 
otras  palabras,  la  instrumentación  proporcionará  una  manera  programable  de  simular  el  com¬ 
portamiento  de  un  jugador,  de  forma  que  se  reduzca  la  carga  de  betatesting.  Gracias  a  esto, 
el  tiempo  de  desarrollo  puede  ser  reducido  considerablemente,  ya  que  esta  fase  es  una  de  las 
mas  costosas. 

4.10.1  Análisis 

Un  videojuego  debe  tener  el  mínimo  número  de  bugs  posible,  ya  que  cualquier  bug  hace 
que  el  gameplay  se  vea  gravemente  afectado.  Sin  embargo,  aunque  es  muy  sencillo  ver  que  el 
juego  tiene  errores  debido  a  los  comportamientos  erróneos  que  se  visualizan  en  la  ejecución 
del  juego,  encontrar  la  fuente  del  error  no  es  nada  trivial.  Los  betatester  puede  pasarse  sema¬ 
nas,  e  incluso  meses,  probando  el  comportamiento  del  juego,  comprobando  condiciones  en 
las  que  ellos  piensan  que  el  juego  puede  fallar,  ya  que  las  personas  encargadas  de  esta  fase 
de  pruebas  tienen  experiencia  realizando  este  tipo  de  actividad. 

La  forma  en  que  los  betatester  prueban  el  juego  es  la  siguiente:  a  través  del  controlador, 
empiezan  a  apretar  los  botones  buscando  que  el  personaje  se  mueva  hasta  una  parte  concreta 
del  escenario,  accionando  alguna  combinación  de  acciones  del  juego  que  puedan  llevarlo  a 
una  situación  inconsistente;  es  decir,  debido  a  que  los  desarrolladores  típicamente  no  tienen 
nada  que  les  ayuden  a  saber  en  qué  sección  del  código  se  generan  los  errores,  mas  allá  de 
las  herramientas  típicas  de  depuración,  los  betatesters  tienen  que  probar  la  mayor  cantidad 
posible  de  combinaciones  de  acciones,  movimientos,...  hasta  que  el  juego  falle. 

Una  de  las  tácticas  que  suelen  realizar  los  des  arrolladores  para  agilizar  el  proceso  es  gene¬ 
rar  escenarios  donde  se  obligue  al  personaje  a  ejecutar  un  tipo  de  acciones;  por  ejemplo,  si 
se  quiere  probar  que  el  mecanismo  de  subida  y  bajada  de  escaleras  funciona  correctamente. 
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se  genera  un  eseenario  lleno  de  esealeras.  El  problema  de  este  procedimiento  es  que  no  es 
automático  y  se  tiene  que  realizar  la  verificación  manualmente,  lo  que  es  costoso  en  tiempo 
y  recursos,  ya  que  no  siempre  es  inmediato  visualizar  si  existe  algún  error. 

En  la  iteración  4.1  se  dieron  los  primeros  pasos  en  la  creación  de  pruebas  automáticas 
añadiéndo  un  log  que  registraba  una  serie  de  eventos  que  se  consideraban  relevantes.  Eas 
pruebas  creadas  estaban  basadas  en  este  log,  de  forma  que  se  esperaba  encontrar  una  serie  de 
mensajes  que  informaran  de  acciones  realizadas  durante  la  ejecución  del  juego.  No  encontrar 
esos  mensajes  era  señal  de  que  el  juego  había  fallado  en  un  punto  del  código  determinado 
por  el  mensaje  restante. 

En  esta  iteración  se  pretende  ir  un  paso  mas  allá,  buscando  crear  tests  que  simulen  el 
comportamiento  de  un  jugador  humano  que  estuviese  probando  una  condición  determinada 
del  juego. 

Para  poder  llevar  a  cabo  esto,  se  hace  necesario  tener  una  forma  alternativa  con  la  que 
interactuar  con  el  videojuego,  que  permita  a  un  test  realizar  una  serie  de  acciones  típicas 
del  usuario  para  el  videojuego  que  se  está  desarrollando  en  este  proyecto:  acelerar  el  coche, 
hacerlo  girar,  frenarlo,  usar  los  powerups,  etcétera. 

4.10.2  Diseño  e  Implementación 

Hay  que  señalar  que  aunque  la  instrumentación  es  algo  que  lleva  muchos  años  realizándo¬ 
se  en  la  industria  del  software,  debido  al  carácter  reservado  de  la  industria  de  los  videojuegos, 
éste  tipo  de  técnicas  ágiles  no  están  muy  divulgadas,  de  forma  que  hay  un  cierto  matiz  inno¬ 
vador  en  esta  iteración. 

Dicho  esto,  la  solución  planteada  aquí  pasa  por  hacer  uso  de  ZeroC  ICE  para  permitir  que 
una  prueba  invoque  una  serie  de  métodos  que  se  definirán  en  slice  de  ZeroC.  Se  expondrá 
el  API  pública  de  las  clases  que  se  quieran  instrumentar  de  forma  que  haciendo  uso  de 
los  mecanismos  de  red  de  ZeroC  ICE  una  prueba  invoque  dichos  métodos,  de  forma  que 
programáticamente  podrá  simular  el  comportamiento  típico  de  un  jugador.  Por  otra  parte,  la 
ventaja  de  crear  pruebas  específicas  para  probar  situaciones  determinadas  en  el  juego  es  que, 
gracias  a  la  flexibilidad  que  aporta  la  forma  en  que  se  crean  los  circuitos,  se  puede  lanzar  la 
prueba  con  un  circuito  determinado,  hacer  que  la  prueba  ejecute  una  serie  de  acciones  sobre 
el  coche,  de  la  misma  forma  en  que  lo  haría  un  jugador  humano,  y  después  comprobar  de 
forma  automática  alguna  condición  que  se  espera  que  se  cumpla. 

A  continuación  se  mostrará  el  proceso  de  creación  de  la  primera  prueba  creada,  en  la  que 
simplemente  se  comprueba  si  el  coche  colisiona  contra  uno  de  los  muros  del  circuito,  de  for¬ 
ma  que  se  ejemplifique  el  proceso  general  que  se  ha  seguido  en  todas  las  demás  pruebas. 

El  primer  paso  que  se  ha  realizado  ha  sido  el  de  definir  la  interfaz  de  ZeroC  creando  un 
archivo  slice  en  el  que  se  definen  las  operaciones.  En  el  listado  4.36  se  puede  ver  la  definición 
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de  dicha  interfaz.  En  él  se  pueden  observar  las  operaciones  mas  importantes  de  la  clase  Car 
y  una  serie  de  estructuras  para  poder  operar  con  los  tipos  de  datos  de  Bullet,  con  los  que 
trabaja  la  clase  Car. 


#include  <Ice/BuiltinSequences . ice> 
module  Tinman  { 

enum  Action  {AccelerateBegin ,  AccelerateEnd, 
BrakeBegin,  BrakeEnd, 

TurnRight,  TurnLeft,  TurnEnd, 
UseNitro} ; 

struct  Quaternion  { 

float  x; 
float  y; 
float  z; 
float  w; 

}; 


struct  VectorB  { 
float  x; 
float  y; 
float  z; 

}; 


interface  InstrumentatedCar  { 

void  exec(Tinman: :Action  action); 

int  getNitro( ) ; 
int  getLapí ) ; 

VectorB  getPosition( ) ; 

VectorB  getVelocityí ) ; 

Quaternion  getOrientation{ ) ; 
VectorB  getDirection(int  factor); 
float  getSpeedO; 
bool  isColliding ( ) ; 

}; 


Listado  4.36:  Slice  que  define  la  clase  InsturmentatedCar 


Tras  esto,  se  compila  el  slice  a  C++  con  la  herramienta  de  ZeroC  slicelcpp.  Después  se 
ha  de  proporcionar  una  implementación  para  las  operaciones  definidas  en  la  interfaz  Instru- 
mentatedCar.  Para  ello,  se  ha  creado  la  clase  InstrumentatedCarI,  que  hereda  de  las  clases 
Car  y  de  InstrumentatedCar,  clase  abstracta  que  autogenera  slice2cpp  y  que  implementa 
una  serie  de  operaciones  de  ZeroC.  En  el  listado  4.38  se  puede  ver  el  código  fuente  de  esta 
clase.  Lo  mas  relevante  de  la  implementación  radica  en  que  por  un  lado  esta  clase  redirige 
las  invocaciones  recibidas  directamente  a  la  clase  Car,  lo  que  demuestra  lo  sencilla  que  es 
la  implementación,  en  contraste  con  la  potencia  que  aporta  este  mecanismo.  Por  otro  que  se 
convierten  los  tipos  de  datos  de  Bullet  a  los  tipos  de  datos  definidos  en  el  slice,  por  ejemplo 
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en  los  método  getPosition  ( ) . 

Al  heredar  de  la  clase  Car  también  comparte  el  mismo  interfaz  y  atributos,  de  forma  que 
el  uso  de  ICE  es  transparente  para  las  demás  clases.  De  esta  forma,  la  prueba  puede  invocar 
las  operaciones  de  la  clase  Car  de  una  forma  similar  a  la  que  lo  hace  un  jugador  humano, 
con  la  diferencia  de  que  este  lo  hace  cuando  presiona  los  botones  del  teclado  y  la  prueba  lo 
hace  invocando  métodos  específicos  para  tal  efecto.  Hay  que  señalar  que  cuando  una  prueba 
invoca  uno  de  los  métodos  definidos  en  el  interfaz  InstrumentatedCar  se  sigue  el  mismo 
flujo  de  ejecución  que  cuando  un  jugador  humano  ejecuta  la  misma  función  como  respuesta 
a  presionar  un  botón  del  teclado. 

Se  ha  creado  también  una  clase  PlayerFactory,  con  la  idea  de  abstraer  la  creación  de  los 
objetos  personaje.  La  implementación  de  esta  clase  se  puede  ver  en  el  listado  4.39.  La  necesi¬ 
dad  de  crear  esta  factoria  de  jugadores  radica  en  que  además  de  los  tres  tipos  de  controladores 
existentes  en  este  punto  del  proyecto  {Human,  NetWork  y  Bot)  hay  que  añadir  uno  nuevo  el 
controlador  Instrumentado. 

Se  ha  añadido  un  modo  de  depuración  al  juego,  en  el  que  sólo  se  da  la  opción  de  crear 
personajes  con  controladores  de  tipo  Bot  y  Instrumentado.  Este  modo  de  depuración  se  ac¬ 
tiva  cuando  se  ejecuta  el  juego  con  unos  determinados  argumentos  por  línea  de  órdenes, 
que  se  verán  a  continuación.  Un  jugador  instrumentado  se  caracteriza  por  tener  un  coche 
instrumentado  y  un  controlador  instrumentado.  El  controlador  instrumentado  es  un  controla¬ 
dor  vacío  que  únicamente  invoca  al  método  car_->update( )  en  su  método  update( ).  Esto  es 
así  debido  a  que  la  idea  de  un  InstrumentatedCar  es  que  las  pruebas  indiquen  qué  acciones 
se  quieren  ejecutar,  de  forma  que  el  controlador  no  es  quien  va  a  indicar  las  acciones  que 
ejecutará  el  coche,  como  ocurre  con  los  otros  tres  tipos  de  controlador,  sino  que  el  propio 
InstrumentatedCar  recibe  las  invocaciones  desde  la  prueba. 

Junto  con  la  adición  de  la  clase  PlayerFactory  se  ha  añadido  CarFactory.  Ea  implemen¬ 
tación  de  esta  clase  se  puede  ver  en  el  listado  4.40.  Cuando  el  juego  se  arranca  en  modo 
depuración,  se  crea  un  adaptador  de  objetos  sobre  el  que  se  registrarán  los  objetos  de  tipo 
InstrumentatedCar  que  creará  esta  factoría,  que  es  lo  permite  que  una  prueba  invoque  los 
métodos  del  coche  instrumentado. 

Una  vez  que  fue  creado  el  soporte  necesario  para  crear  pruebas,  el  siguiente  paso  consiste 
en  crearlas.  En  el  listado  4.37  se  puede  ver  el  código  de  una  de  las  pruebas  creadas.  En  esa 
prueba  se  quiere  comprobar  si  los  bots,  una  vez  se  atascan  contra  una  pared,  son  capaces 
de  salir.  Este  era  un  problema  que  existía  en  el  proyecto  y  mediante  la  prueba  mostrada  se 
consiguió  eliminar. 

Cabe  destacar  que  la  prueba  se  ha  escrito  en  Python  para  poder  demostrar  que  en  realidad 
no  está  accediendo  directamente  al  motor  de  juego,  sino  que  interacciona  con  el  juego  a 
través  de  la  clase  InstrumentatedCarl.  Además,  de  esa  forma  se  ve  la  flexibilidad  que  aporta 
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utilizar  ICE,  dado  que  no  se  está  sujeto  a  un  lenguje  determinado  para  crear  pruebas. 


class  RemoteGaine(object) : 

def _ init _ (self ) : 

self.cars  =  [] 

self. broker  =  Ice.initialize( ) 

def  add_car(self ,  proxy): 

proxy  =  self . broker. stringToProxy (proxy) 

self . cars . append (Tinman . Inst rumentatedCarPrx . checkedCast (proxy) ) 

def  get_car(self ,  índex): 
return  self .cars[index] 


class  TestBotDontGetStuck(unittest.TestCase) : 
def  setUp(self ) : 

server  =  SubProcess ( " . /main  --bots  1  --track  config/circuit . data  --frames  360",  stdout=sys. 
stdout) 

server. startO 

wait_that(localhost,  listen_port ( 10000) ) 
self.game  =  ReinoteGame( ) 

self .game.add_car( "BotO:  tcp  -h  127.0.0.1  -p  10000") 

self. caro  =  self  .gaine.get_car(0) 

self  .caro. niove(Tinman.Vector3(-l,  2,  -40)) 

self . addCleanup( server . termínate) 

def  test_ríght_l(self ) : 
tíme. sleep(5) 

self . assertFalse( self . carO . ísStuck( ) ) 

waít_that (self . carO . ísStuck,  call_wíth ( ) . returns (T rué) ) 


tíme. sleep(2) 

self . assertFalse( self . carO . ísStuck( ) ) 
def  runTest(self ) : 

self . assertT  rué ( self . game. Icar . ísCollídíng ( ) ) 

Listado  4.37:  Prueba  haciendo  uso  de  la  clase  InsturmentatedCar. 

En  el  SetUp  de  la  prueba,  se  lanza  el  juego  como  un  subproceso.  Es  necesario  lanzar  el 
juego  dentro  de  la  prueba  de  esta  forma  debido  a  que  como  la  ejecución  del  juego  se  realiza 
dentro  de  un  bucle  infinito,  hasta  que  este  no  finalizase  la  prueba  quedaría  bloqueada. 

Es  necesario  que  la  prueba  pueda  inicializar  el  juego  en  un  contexto  determinado.  Para 
ello,  se  ha  añadido  al  juego  una  serie  de  comandos  por  línea  de  órdenes.  A  través  de  ellos  se 
puede  inicializar  el  juego  con  un  circuito  determinado,  con  una  serie  de  jugadores  controla¬ 
dos  por  la  prueba,  con  un  número  determinado  de  bots  e  incluso  se  puede  indicar  al  motor 
de  juego  que  renderice  las  cajas  de  contorno  de  las  mallas  3D  para  realizar  una  depuración 
visual  de  la  geometría  de  la  escena.  Eos  argumentos  añadidos  en  esta  iteración  son: 

■  -debugRender:  permite  renderizar  las  formas  de  colisión  de  los  cuerpos  físicos. 
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■  -track  <fichero>:  arranca  el  juego  con  un  circuito  determinado 

■  -players  <numero>:  crea  un  determinado  número  de  jugadores  instrumentados.  Siem¬ 
pre  menor  o  igual  a  4. 

■  -bots  <número>:  crea  un  determinado  número  de  bots.  La  suma  de  los  jugadores  ins¬ 
trumentados  y  de  los  bots  no  puede  superar  4. 

■  -trames  <numero>:  el  juego  se  ejecutará  un  número  de  frames. 

La  prueba  del  listado  4.37  hace  uso  de  esta  característica  del  motor  de  juegos  para  indi¬ 
carle  el  tipo  de  circuito(‘circuit.data’),  el  número  de  bots  (1)  y  el  número  de  frames  que  se 
ejecutará  el  juego  (360). 

Una  vez  que  se  ha  arrancado  el  juego,  se  crea  un  proxy  del  instrumentatedCar  que  utiliza 
el  bot,  usando  el  método  add_car  de  la  clase  RemoteGame.  Una  vez  creado,  el  método  hace  uso 
de  dicho  proxy  mediange  el  método  get_car(index). 

El  siguiente  paso  consiste  en  generar  un  contexto  adecuado.  En  esta  prueba  se  quiere 
comprobar  que  los  bots  son  capaces  de  chocar  contra  una  pared  y  continuar  con  la  carrera 
de  forma  normal.  Para  generar  esta  situación,  se  mueve  el  coche  creado  en  la  prueba  hasta 
una  posición  cercana  a  un  muro  y  se  deja  que  la  lA  haga  el  resto.  Ea  figura  4.20  muestra  el 
momento  en  que  ha  finalizado  el  Setup  de  la  prueba  y  comienza  a  verificarse  las  condiciones 
del  test. 

Ea  solución  al  problema  radicaba  en  mejorar  la  forma  en  que  se  detectaban  las  colisiones 
contra  los  muros,  algo  que  fue  posible  detectar  gracias  a  que  con  cada  modificación  en  el 
algoritmo  de  lA  se  ejecutaba  este  test  y  se  comprobaba  el  efecto  que  las  modificaciones 
realizadas  sobre  el  código  tenían  sobre  el  algoritmo. 

Esta  es  una  de  las  ventajas  que  aportan  los  test  automáticos:  son  reproducibles  con  un  coste 
cercano  a  cero  (este  test  tarda  4  segundos  en  ejecutarse),  lo  que  agiliza  mucho  el  proceso  de 
desarrollo,  aportando  feedback  al  ingeniero  acerca  de  los  cambios  que  está  realizando. 


void 

Tinman: : InstrumentatedCarI : :exec( : :Tinman: :Action  action, 

const  Ice: :Current&  current)  { 

Car: :exec{action) ; 

} 


: :Ice: :Int 

Tinman: lInstrumentatedCarI: :getNitro(const  Ice: :Current&  current)  { 
return  Car: :get_nitro() ; 

} 


: :Ice: :Int 

Tinman: :InstrumentatedCarI: :getLap(const  Ice: :Current&  current)  { 
return  Car: :get_lap( ) ; 

} 
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: iTinman : : VectorB 

Tinman: ilnstrumentatedCarl: :getPosition{const  Ice: :Current&  current)  { 
btVectorS  position  =  Car: :get_position{ ) ; 
return  {position . getX( ) ,  position .getY{ ) ,  position . getZ( )} ; 

} 

:  :Tininan :  : VectorB 

Tinman:  :InstruinentatedCarI:  :getVelocity(const  Ice:  :Current&  current)  { 
return  {Car : : get_veIocity( ) . x( ) ,  Car: :get_velocity( ) .y( ) , 

Car : : get_velocity{ ) . z ( ) } ; 

} 

: :Tinman: :Quaternion 

Tinman:  :InstruinentatedCarI:  :getOrientation(const  Ice:  :Current&  current)  { 
return  {Car : : get_orientation ( ) . getX( ) , 

Car : : get_orientation ( ) . getY( ) , 

Car : : get_orientation ( ) . getZ( ) , 

Car : : get_orientation ( ) . getW( ) } ; 

} 


: :Tinman : : VectorB 

Tinman: : InstrumentatedCarI : :getDirection{ : :Ice: :Int  factor, 

const  Ice: :Current&  current) 

return  {Car : : get_direction{ ) .x( ) ,  Car : : get_direction ( ) . y ( ) , 

Car : : get_direction ( ) . z ( ) } ; 


} 


{ 


: : Ice : : Float 

Tinman: :InstrumentatedCarI: :getSpeed(const  Ice :: Cúrrente  current)  { 
return  Car: :get_speed( ) ; 

} 


bool 

Tinman: :InstrumentatedCarI: :isColliding{const  Ice: :Current&  current)  { 
return  Car : : is_colliding { ) ; 

} 


bool 

Tinman: :InstrumentatedCarI: :isStuck(const  Ice: :Current&  current)  { 
return  is_stuck( ) ; 

} 

void 

Tinman: : InstrumentatedCarI : :move(const  : :Tinman: :VectorB&  position, 

const  Ice: :Current&  current)  { 
btVectorB  new_position(position.x,  position. y,  position. z); 
set_ position ( new_ position) ; 

} 


Listado  4.38:  clase  InstrumentatedCarI 


Player: : shared 

HumanFactory: :create(std: :string  nick,  EventListener: :shared  input, 

Sound :: shared  sound,  Car::shared  car)  { 

HumanController: :KeyBinding  player_bindings  { 

{OIS: :KC_W,  {Tinman: :Action: :AccelerateBegin,  Tinman: :Action: :AccelerateEnd}}, 
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{OIS: :KC_S,  {Tinman: lAction: :BrakeBegin,  Tinman: :Action: : BrakeEnd}} , 

{OIS: :KC_A,  {Tinman: :Action: :TurnLeft,  Tinman: :Action: :TurnEnd}}, 

{OIS: :KC_D,  {Tinman: :Action: :TurnRight,  Tinman: :Action: :TurnEnd}}, 

{OIS: :KC_SPACE,  {Tinman: :Action: :UseNitro,  Tinman: :Action: :AccelerateEnd}} 


Controller :: shared  human_controller  = 

std: :make_shared<HumanController>(input,  player_bindings ,  car); 
return  std : :make_shared<Player>(nick,  human_controller,  sound); 

} 

Player: : shared 

BotFactory: :create(std: :string  nick,  Physics :: shared  physics, 

Sound :: shared  sound,  Race::shared  race,  Car::shared  car){ 

BotController: : shared  bot  =  std: :make_shared<BotController>(physics,  car); 
std : : dy namic_ poin t e r_cast<Bot Control le r>( bot ) ->add_race( race) ; 
return  std : :make_shared<Player>{nick,  bot,  sound); 

} 

Player: : shared 

NetworkFactory: :create{std: :string  nick,  Sound :: shared  sound,  Car::shared  car){ 
NetworkController: : shared  controller  =  std : :make_shared<NetworkController>(car) ; 
return  std : :make_shared<Player>{nick,  controller,  sound); 

} 

Player: : shared 

InstrumentatedFactory: :create(std: :string  nick,  Sound :: shared  sound. 

Car: : shared  car)  { 

std::cout  «  "[InstrumentatedFactory]  create"  «  std::endl; 

IController: : shared  controller  =  std: :make_shared<IController>(car) ; 
return  std : :make_shared<Player>(nick,  controller,  sound); 


Listado  4.39:  clase  PlayerFactory 


CarFactory: :CarFactory{Ice: :ObjectAdapterPtr  adapter)  { 
adapter_  =  adapter; 
instrumentated_  =  true; 

} 

Car:  : shared 

CarFactory: :create(std: :string  nick)  { 
if ( ! inst rumen tated_) 

return  std : :make_shared<Car>(nick) ; 

auto  car  =  std: :make_shared<Tinman: :InstrumentatedCarI>(nick) ; 

Ice: :ObjectPrx  peer_proxy  =  adapter_->add(car.get( ) , 

adapter_->getCommunicator( ) ->stringToIdentity{nick) ) ; 
auto  peer  =  Tinman :: Inst rumentatedCarPrx: : checkedCast {peer_proxy->ice_twoway ()) ; 
return  car; 

} 


Listado  4.40:  clase  CarFactory 
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Figura  4.20:  Resultado  de  la  iteración  10 

4.11  Análisis  de  costes 

Para  realizar  un  análisis  del  coste  del  proyecto,  se  ha  utilizado  la  herramienta  Sloccount  [Whe] . 
Sloccount  se  basa  en  el  modelo  COnstructive  COst  MOdel  (COCOMO)  [y AMOS].  Esta  herra¬ 
mienta  da  tres  resultados:  por  un  lado,  el  número  de  líneas  de  código  fuente  por  directorio  y 
por  lenguaje  de  programación.  Por  otro,  el  número  de  líneas  de  código  fuente  por  lenguaje. 

Por  último,  da  una  estimación  de  esfuerzo,  de  duración  y  de  coste  del  proyecto  basado  en  los 
datos  anteriores. 

Para  estimar  el  esfuerzo,  el  modelo  cocomo  tiene  en  cuenta  una  productividad  media  por 
desarrollador  y  una  sobrecarga  de  trabajo  dependiendo  del  tipo  de  proyecto.  Para  estimar  el 
coste  del  proyecto,  multiplica  lo  anterior  por  el  coste  por  desarrollador/año 

Por  tanto,  según  el  cuadro  4.11  este  proyecto  tiene  un  coste  de  226, 1 34  €,  con  una  duración 
estimada  de  9.36  meses  y  4  desarolladores 

Para  calcular  todos  estos  valores  se  han  utilizado  los  valores  por  defecto  que  se  usan  nor¬ 
malmente  en  COCOMO,  en  modo  orgánico: 

■  factor  de  esfuerzo  =  2.4,  exponente  =  1.05 

■  factor  de  planificación  =  2.5,  exponente  =  0.38 


*'Se  ha  estimado  que  cada  desarrollador  tiene  un  coste  de  35.000 €/año 
'^se  entiende  que  3.45  desarrolladores  son  4 
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SEOC 

Directory 

SEOC-by-Eanguage  (Sorted) 

6809 

src_network 

cpp=6745,python=64 

1454 

src_model 

cpp=1454 

959 

src_managers 

cpp=95 

936 

srch_util 

cpp=936 

661 

srch_stat 

cpp=661 

494 

src_controller 

cpp=494 

279 

examples 

py  thon=  177  ,cpp=  102 

273 

src_top_dir 

cpp=268,sh=5 

21 

Util 

sh=19,python 

Cuadro  4.1:  Eíneas  de  código  fuente  por  directorio  y  lenguaje 

Líneas  totales  por  lenguaje 


cpp 

11619  (97.70%) 

python 

243  (2.04  %) 

sh 

24  (0.20  %) 

lisp 

7  (0.06  %) 

Cuadro  4.2:  Líneas  de  código  totales  divididas  por  lenguaje  de  programación 


Líneas  físicas  de  código  fuente  (SLOC)  1 1,893 

Esfuerzo  estimado  de  desarrollo,  Persona-Año  (Persona-Mes)  2.69  (32.30) 
Planificación  estimada.  Años  (Mes)  0.78  (9.36) 

Numero  estimado  de  desarrolladores  (Esfuerzo/Planificado)  3.45 
Coste  total  estimado  del  desarrollo  226,1 34  € 

Cuadro  4.3:  Coste  total  estimado  del  proyecto 
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Capítulo  5 


Arquitectura  del  Motor 


A  Raíz  del  desarrollo  del  videojuego  se  ha  ido  creando  una  serie  de  clases  de  utilidad  con 
el  propósito  de  solucionar  los  problemas  que  han  ido  surgiendo  durante  el  transcurso 
del  proyecto.  Debido  al  esfuerzo  invertido  en  que  el  diseño  sea  flexible  y  en  que  la  lógica  de 
control  esté  lo  mas  desacoplada  posible  de  los  modelos  de  datos,  se  ha  conseguido  crear  una 
primera  aproximación  a  lo  que  será  un  motor  de  juegos  propio. 

En  este  capitulo  se  explicará  cuál  es  la  jerarquía  de  clases  que  conforman  el  motor  de 
juego  de  este  proyecto.  Las  clases  mas  importantes  del  proyecto  son  las  siguientes: 

■  Clase  Game:  clase  principal.  Contiene  referencias  a  todos  los  gestores  y  alberga  el 
bucle  de  juego.  Al  crear  una  instancia  de  esta  clase  se  inicializa  el  motor  de  juego. 

■  Gestores  de  utilidades:  Son  clases  de  utilidad  que  ayudan  a  gestionar  los  elementos 
de  la  escena,  los  cuerpos  físicos,  los  efectos  de  sonido,  la  interfaz  gráfica,  etcétera. 

■  Jerarquía  de  estados:  Un  estado  es  una  abstracción  que  define  el  comportamiento  del 
juego  en  un  momento  determinado.  Gracias  a  esta  abstracción  es  posible  desacoplar  la 
lógica  de  control  del  bucle  principal  del  juego. 

■  Jerarquía  de  controladores:  Un  controlador  es  una  clase  que  permite  desacoplar  la 
lógica  de  control  de  la  clase  Player.  Gracias  a  esto,  es  posible  crear  de  forma  transpa¬ 
rente  diferentes  tipos  de  jugadores. 

■  Sesión  de  juego:  Clase  que  modela  una  sesión  de  juego. 

■  Clase  Race  y  Track:  La  clase  race  sirve  como  interfaz  sobre  la  que  obtener  informa¬ 
ción  relativa  a  la  carrera.  La  clase  Track  representa  un  circuito. 

■  Clase  Car:  encapsula  la  información  relativa  al  vehículo. 

En  la  siguientes  secciones  explicará  detalladamente  algunos  de  los  aspectos  mas  impor¬ 
tantes  de  las  clases  que  conforman  el  listado  anterior. 

5.1  Clase  Game 

Es  la  clase  principal  del  juego.  Al  crear  una  instancia  se  inicializan  cada  uno  de  los  gestores 
de  utilidad  que  se  usarán  para  inicializar  los  demás  componentes  del  juego.  Unicamente  hay 
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que  crear  una  única  instancia  de  esta  clase  por  cada  juego  que  se  quiera  ejecutar.  Cuando  una 
clase  del  motor  de  juego  necesita  tener  acceso  a  alguno  de  los  gestores,  este  es  inyectado  a 
través  del  constructor  de  dicha  clase.  De  esta  forma,  se  tiene  un  lugar  específico  donde  se 
crean  las  instancias  de  las  clases  que  representan  el  núcleo  del  motor  del  juego. 

Una  vez  que  se  llama  al  método  start  de  esta  clase,  se  inicia  el  proceso  de  arranque  del 
juego,  renderizándose  el  menú  principal  en  la  ventana  que  se  crea  para  mostrar  el  juego  para, 
acto  seguido,  comenzar  a  ejecutar  el  bucle  principal  del  juego. 

Es  importante  señalar  que  el  bucle  principal  del  juego  es  la  estructura  de  control  mas 
importante  de  este.  Desde  ese  punto  es  donde  se  ejecutará  cualquier  tipo  de  lógica  que  sea 
necesaria  en  él.  En  el  listado  5.1  se  puede  ver  el  código  fuente  del  mismo. 


void 

Game: : step{ )  { 

delta_  +=  timer_ . get_delta_time( ) ; 
input_->capture( ) ; 
if (delta.  >=  (1/FPS))  { 
input_->check_events ( ) ; 

state_machine_->get_current_state{ ) ->update(delta_) ; 
scene_ -> rende r_one_frame( ) ; 
delta.  =  O.f; 

} 

} 


Eistado  5.1:  Instrucciones  que  se  ejecutan  en  el  bucle  de  juego. 

Una  vez  que  se  destruye  la  instancia  de  esta  clase,  el  juego  se  cierra. 

5.2  Gestores  de  utilidad 

Este  conjunto  de  clases  son  en  realidad  una  serie  de  wrappers  que  encapsulan  la  funcio¬ 
nalidad  de  las  diversas  bibliotecas  que  se  han  usado  durante  el  desarrollo  del  proyecto.  Estas 
son: 

■  Scene:  encapsula  la  funcionalidad  de  OgreSD.  Implementa  una  serie  de  funciones  que 
facilitan  la  creación  de  elementos  típicos  en  una  escena  de  un  videojuego:  planos, 
nodos  de  escena  y  entidades  de  Ogre,  luces,  cámaras.  Eacilita  realizar  operaciones 
geométricas  sobre  los  nodos  de  escena,  así  como  añadir  o  eliminar  nodos  al  grafo 
de  escena,  añadir  nuevos  viewports  a  la  cámara,  añadir  luces,  el  tipo  de  algoritmo  de 
generación  de  sombras,  etcétera. 

■  Physics:  encapsula  llamadas  a  Bullet  Physics.  Eacilita  realizar  operaciones  sobre  cuer¬ 
pos  rígidos(movimiento,  rotación,  aplicación  de  fuerzas,  etcétera)  y  creación  de  diver¬ 
sas  formas  de  colisión.  El  módulo  de  dinámica  de  vehículos  de  Bullet  Physics  facilita 
la  implementación  de  la  Car. 

■  EventEistener:  Clase  que  permite  gestionar  los  eventos  de  teclado  y  ratón.  Permite 
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añadir  callbacks  asociados  a  un  evento  de  pulsación  o  levantado  de  una  tecla,  bien  de 
teclado  o  de  ratón.  A  la  hora  de  detectar  qué  teclas  se  han  pulsados,  se  hace  uso  de  la 
funcionalidad  ofrecida  por  la  biblioteca  OIS. 

■  GUI:  clase  que  encapsula  funciones  de  creación  de  Overlays  de  OgreSD,  así  llamadas 
de  CEGUI  que  hacen  mas  sencilla  la  creación  de  elementos  para  la  interfaz  gráfica: 
cuadros  de  texto,  botones,  ventanas,  barras  de  progreso,  etcétera. 

■  Sound:  clase  que  encapsula  llamadas  a  la  biblioteca  Simple  SirectMedia  Layer  (SDL). 
Se  encarga  de  gestionar  los  recursos  de  sonido  del  videjuego:  ejecutar  efectos  de  soni¬ 
do,  bucles  musicales,  cargar  ficheros  de  sonido  para  que  sean  utilizables  por  el  video¬ 
juego,  etcétera. 

Estas  clases  permiten  reducir  el  tiempo  de  desarrollo  en  nuevos  proyectos,  ya  que  ofrecen 
una  serie  de  operaciones  muy  comunes  que  se  hacen  necesarias  durante  el  desarrollo  de  un 
videojuego,  que  las  bibliotecas  originales  no  implementan.  Por  ejemplo,  a  la  hora  de  crear 
un  escenario,  las  clase  Scene  y  Physics  facilitan  la  labor  de  gestionar  los  cuerpos  que  la 
componen. 

5.3  Jerarquía  de  estados 

Un  videojuego  es  un  programa  complejo,  el  cual  tiene  una  serie  de  comportamientos  di¬ 
ferentes  dependiendo  del  punto  del  videojuego  en  que  se  encuentre  el  jugador.  Por  ejemplo, 
si  este  está  en  el  menú  principal,  el  juego  deberá  darle  acceso  al  jugador  a  los  ranking,  a  un 
menú  de  opciones,  así  como  de  comenzar  la  partida,  todo  esto  a  través  de  una  serie  de  boto¬ 
nes.  Si  se  encuentra  en  mitad  de  la  partida,  el  juego  deberá  darle  la  posibilidad  al  jugador  de 
controlar  su  vehículo. 

Por  tanto,  existe  un  problema:  se  tiene  una  gran  variedad  de  comportamientos  que  se 
deben  gestionar  dependiendo  del  contexto  actual  del  videojuego  en  cada  momento.  Debido 
a  que  toda  la  lógica  del  videojuego  se  ejecuta  en  el  bucle  principal,  en  principio  la  lógica  que 
define  cada  uno  de  estos  comportamientos  y  la  lógica  de  control  que  permite  seleccionar  un 
comportamiento  u  otro  deberá  estar  acoplada  en  el  bucle  principal.  Para  poder  resolver  este 
problema  se  decidió  usar  una  clase  abstracta  que,  heredando  de  ella,  permitiese  encapsular 
diferentes  tipos  de  lógica,  de  forma  que  fuese  posible  desacoplarla  del  bucle  principal. 

En  el  listado  5.1  se  muestra  el  mecanismo  que  permite  desacoplar  la  lógica  de  control  del 
bucle  de  juego.  Ea  variable  State _machine_  es  una  instancia  de  la  clase  StateMachine .  Esta 
clase  encapsula  la  lógica  necesaria  para  poder  cambiar  entre  los  diferentes  estados  del  juego, 
ademas  de  dar  acceso  a  los  propios  estados. 

El  método  update  de  la  clase  State  está  pensado  para  actualizar  la  lógica  del  juego  de  forma 
transparente.  Cada  uno  de  los  estados  implementará  dicho  método  de  forma  que,  dependien¬ 
do  del  estado  actual,  se  ejecutará  una  lógica  u  otra;  por  ejemplo,  en  el  update  del  estado  Play 
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se  actualiza  el  estado  de  la  sesión  de  juego,  mientras  que  en  el  update  del  estado  Results  se 
actualizan  los  rankings.  En  la  figura  5.1  se  puede  ver  la  jerarquía  de  estados. 


Figura  5.1:  Diagrama  UML  de  la  Jerarquía  de  estados 


5.4  Controladores  de  jugador 

De  forma  similar  al  problema  de  los  estados,  existe  un  problema  relativo  a  los  jugadores. 
En  el  juego  que  se  está  desarrollando  existen  tres  perfiles  distintos  que  definen  el  comporta¬ 
miento  de  un  jugador: 

■  Human:  este  tipo  de  jugador  ejecuta  sus  acciones  en  respuesta  a  eventos  de  teclado, 
ratón  o  de  un  joystick. 

■  Bot:  es  un  jugador  que  es  controlado  por  un  algoritmo  de  inteligencia  artificial. 

■  NetWork:  este  tipo  de  jugador  representa  a  un  jugador  remoto  dentro  de  una  partida  en 
red.  Se  dice  que  un  jugador  es  remoto  cuando  la  instancia  del  jugador  no  se  encuentra 
en  la  misma  máquina  que  la  que  está  usando  el  jugador  humano;  es  decir,  en  una 
partida  en  red,  los  jugadores  remotos  son  aquellos  que  no  son  el  jugador  humano  y 
que  no  son  bots. 

De  la  misma  forma  que  en  la  sección  5.3,  existe  el  problema  de  desacoplar  la  lógica  de 
control  del  propio  jugador.  Para  esto,  se  ha  creado  un  clase  Controller.  El  objetivo  de  esta 
clase  es  encapsular  la  lógica  de  control.  Ea  clase  Player  encapsula  una  instancia  de  dicha 
clase. 

Ea  clase  Controller,  al  igual  que  la  clase  Player,  es  una  clase  abstracta.  Esto  permite 
realizar  diversas  implementaciones  de  dicha  clase  dependiendo  de  las  necesidades.  En  la 
figura  5.2  se  muestra  la  jerarquía  de  controladores. 
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Figura  5.2:  Jerarquía  de  eontroladores 


5.5  Clase  Sesión 

Esta  elase  representa  una  sesión  de  juego.  Eneapsula  la  funeionalidad  neeesaria  para  ini- 
eiar  una  earrera,  erear  todos  los  jugadores  neeesarios,  gestionar  los  tiempos  de  eada  vuelta, 
la  puntuaeión  de  los  jugadores  y  ejeeutar  la  simulaeión  físiea  de  la  earrera. 

5.6  Clase  Car 

Esta  elase  inieializa  un  vehíeulo  de  Bullet  Physies.  Para  desaeoplar  la  lógiea  de  eontrol  de 
la  elase  Car,  se  implementa  un  patrón  Command  que  invoea  funeiones  de  una  elase  CarCon- 
troller.  Dieha  elase  tiene  el  mismo  objetivo  que  los  eontroladores  de  jugador,  desaeoplar  la 
lógiea  de  eontrol  de  los  modelos  de  datos. 
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Capítulo  6 


Metodología  y  herramientas 


En  este  capítulo  se  tratará  de  explicar  las  particularidades  de  la  metodología  de  traba¬ 
jo  utilizada  durante  el  desarrollo  de  este  proyecto.  Por  otra  parte,  se  enumerarán  las 
tecnologías  usadas  para  desarrollarlo. 

6.1  Metodología  usada  en  este  proyecto 

Antes  de  profundizar  acerca  de  las  metodologías  que  se  ha  intentado  seguir  en  este  pro¬ 
yecto,  es  importante  poner  en  contexto  al  lector. 

En  este  proyecto  se  han  creado  una  serie  de  pruebas  automáticas  sobre  el  videojuego  que 
se  ha  desarrollado.  A  la  hora  de  crear  estas  pruebas  ha  sido  necesario  implementar  todo 
una  serie  de  técnicas  de  instrumentación  del  motor  de  juego.  Debido  a  que  era  necesario 
implementar  estos  mecanismos  antes  de  crear  la  prueba,  no  ha  sido  posible  utilizar  TDD 
desde  el  primer  momento  en  este  proyecto. 

Por  otra  parte,  la  aplicación  de  testing  automático  sobre  videojuegos  es  algo  muy  novedo¬ 
so.  Si  a  eso  se  le  suma  el  carácter  cerrado  de  la  industria,  se  puede  comprender  que  existe 
una  complejidad  añadida,  debido  a  que  las  compañías  que  aplican  testing  automático  a  sus 
desarrollos  no  comparten  este  tipo  de  conocimientos. 

Por  tanto,  aunque  lo  ideal  hubiese  sido  aplicar  TDD  desde  el  primer  momento,  esto  no  ha 
sido  posible,  de  forma  que  se  han  ido  aplicando  técnicas  de  testing  automático  en  la  medida 
en  que  los  componentes  que  daban  el  soporte  necesario  iban  siendo  implementados. 

En  cuando  a  la  metodología  aplicada,  se  ha  seguido  un  proceso  iterativo  e  incremental,  en 
el  cuál  cada  una  de  las  iteraciones  comenzaba  sobre  el  trabajo  de  la  anterior  y  buscando  en 
todo  momento  crear  ejemplos  funcionales.  Ea  razón  de  usar  este  tipo  de  metodología  es  que 
un  videojuego  se  presta  a  crear  pequeñas  demos  que  muestren  una  determinada  carectística, 
así  como  a  ir  añadiendo  mas  características  a  estas  demos. 

Por  ejemplo,  en  un  juego  se  puede  hacer  un  ejemplo  en  el  que  se  muestra  un  escenario,  y 
después,  añadir  un  personaje.  Mas  adelante  se  podría  dotar  de  movimiento  a  dicho  personaje, 
tras  lo  que  se  podría  añadir  enemigos,  dotarlos  de  una  lA  cada  vez  mas  sofisticada,  y  así 
sucesivamente. 
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6.2  Desarrollo  Agil 

En  esta  sección  se  expondrán  los  detalles  que  definen  un  proceso  de  desarrollo  ágil,  co¬ 
menzando  con  el  documento  que  dio  origen  a  dicho  movimiento,  el  manifiesto  ágil. 

6.2.1  Manifiesto  por  el  desarrollo  ágil  del  software 

En  2001,  Kent  Beck  y  otros  16  notables  des  arrolladores  de  software,  escritores  y  consul- 
tores(grupo  conocido  como  la  Alianza  Ágil,  firmaron  el  Manifiesto  por  el  desarrollo  ágil  del 
software  [Alia].  En  él  se  establecía  lo  siguiente: 

“Estamos  descubriendo  formas  mejores  de  desarrollar  software,  por  medio  de  hacerlo  y 
de  dar  ayuda  a  otros  para  que  lo  hagan.  Ese  trabajo  nos  ha  hehco  valorar: 

■  Eos  individuos  y  las  acciones,  sobre  los  procesos  y  las  herramientas. 

■  El  software  que  funciona,  mas  que  la  documentación  exhaustiva. 

■  Ea  colaboración  con  el  cliente,  y  no  tanto  la  negociación  del  contrato. 

■  Responder  al  cambio,  mejor  que  apegarse  a  un  plan. 

Es  decir,  si  bien  son  valiosos  los  conceptos  que  aparecen  en  segundo  lugar,  valoramos  mas 
los  que  aparecen  en  primer  lugar. 

Por  otra  parte,  los  doce  principios  del  desarrollo  ágil  [Allb]  son: 

■  Ea  mayor  prioridad  es  satisfacer  al  cliente  mediante  la  entrega  temprana  y  continua  de 
software  con  valor. 

■  Se  acepta  que  los  requisitos  cambien,  incluso  en  etapas  tardías  del  desarrollo.  Eos  pro- 
cesos  Agiles  aprovechan  el  cambio  para  proporcionar  ventaja  competitiva  al  cliente. 

■  Se  entrega  software  funcional  frecuentemente,  entre  dos  semanas  y  dos  meses,  con 
preferencia  al  periodo  de  tiempo  más  corto  posible. 

■  Eos  responsables  de  negocio  y  los  desarrolladores  trabajan  juntos  de  forma  cotidiana 
durante  todo  el  proyecto. 

■  Eos  proyectos  se  desarrollan  en  torno  a  individuos  motivados.  Hay  que  darles  el  en¬ 
torno  y  el  apoyo  que  necesitan,  y  confiarles  la  ejecución  del  trabajo. 

■  El  método  más  eficiente  y  efectivo  de  comunicar  información  al  equipo  de  desarrollo 
y  entre  sus  miembros  es  la  conversación  cara  a  cara. 

■  El  software  funcionando  es  la  medida  principal  de  progreso. 

■  Eos  procesos  Agiles  promueven  el  desarrollo  sostenible.  Eos  promotores,  desarrolla¬ 
dores  y  usuarios  deben  ser  capaces  de  mantener  un  ritmo  constante  de  forma  indefini¬ 
da. 

■  Ea  atención  continua  a  la  excelencia  técnica  y  al  buen  diseño  mejora  la  Agilidad. 
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■  La  simplicidad,  o  el  arte  de  maximizar  la  cantidad  de  trabajo  no  realizado,  es  esencial. 

■  Las  mejores  arquitecturas,  requisitos  y  diseños  emergen  de  equipos  auto-organizados. 

■  A  intervalos  regulares  el  equipo  reflexiona  sobre  cómo  ser  más  efectivo  para  a  conti¬ 
nuación  ajustar  y  perfeccionar  su  comportamiento  en  consecuencia. 

En  las  siguientes  secciones  se  desarrollarán  cada  uno  de  estos  puntos. 

6.2.2  Proceso  ágil 

Según  [PrelO],  cualquier  proceso  de  software  ágil  se  caracteriza  por  la  forma  en  la  que 
aborda  cierto  número  de  suposiciones  clave  acerca  de  la  mayoría  de  proyectos  de  softwa¬ 
re: 

1 .  Es  difícil  predecir  qué  requerimientos  de  software  persistirán  y  cuáles  cambiarán.  Tam¬ 
bién  es  difícil  pronosticar  cómo  cambiarán  las  prioridades  del  cliente  a  medida  que 
avanza  el  proyecto. 

2.  Para  muchos  tipos  de  software,  el  diseño  y  la  construcción  están  superpuestos;  es  decir, 
ambas  actividades  deben  ejecutarse  de  forma  simultánea,  de  modo  que  los  modelos  de 
diseño  se  prueben  a  medida  que  se  crean.  Es  difícil  predecir  cuánto  diseño  se  necesita 
antes  de  que  se  use  la  construcción  para  probar  el  diseño. 

3.  El  análisis,  el  diseño,  la  construcción  y  las  pruebas  no  son  tan  predecibles  como  sería 
deseable  (desde  el  punto  de  vista  de  la  planificación). 

Dadas  estas  tres  suposiciones,  la  metodología  ágil  intenta  combatir  la  impredecibilidad 
de  los  proyectos  software  mediante  la  adaptabilidad  del  proceso  al  cambio  del  proyecto  y  a 
las  condiciones  técnicas.  Para  lograr  esa  adaptabilidad,  se  requiere  un  desarrollo  incremental 
del  proyecto,  apoyando  cada  uno  de  los  incrementos  de  trabajo  en  la  retroalimentación  del 
cliente,  de  modo  que  sea  posible  hacer  las  adaptaciones  apropiadas.  Esto  se  consigue  a  través 
de  la  entrega  de  prototipos  o  porciones  funcionales  del  sistema  en  construcción. 

6.2.3  Test-driven  development  (TDD) 

El  desarrollo  de  videojuegos  es  una  labor  muy  susceptible  a  errores.  Tener  pruebas  que 
ayuden  a  ver  que  el  código  que  vamos  generando  no  produce  conflictos  con  el  previamente 
existente  es  clave  a  la  hora  de  desarrollar  un  producto  de  mayor  calidad. 

TDD  es  una  metodología  ágil  de  desarrollo  software  creada  por  Kent  Beck.  Se  fundamenta 
en  guiar  la  creación  del  software  a  partir  de  las  pruebas,  típicamente  unitarias.  En  la  figura  6. 1 
se  muestra  el  flujo  de  trabajo  que  sigue  esta  metodología. 

Según  [Bec03],  los  pasos  que  sigue  esta  metodología  son  los  siguientes: 

^https ://upload  .wikimedia . org/wikipedia/commons/9/9c/Test- d  riven.development . PNG 
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Figura  6.1:  Flujo  de  trabajo  con  TDD^ 

1.  Añadir  un  test.  En  TDD  cada  nueva  característica  que  se  quiera  añadir  al  sistema  co¬ 
mienza  con  la  escritura  de  un  test.  Para  escribir  un  test,  el  desarrollador  debe  entender 
cláramente  las  especiñcaciones  y  requisitos.  Esto  hace  que  el  desarrollador  se  centre 
únicamente  en  los  requisitos  del  proyecto  antes  de  escribir  el  código,  eliminando  lo 
que  se  conoce  como  código  muerto 

2.  Ejecutar  todos  los  test  para  ver  si  el  mas  nuevo  de  ellos  falla.  Esto  permite  que  el 
test  mas  reciente  no  da  un  falso  positivo.  Debido  a  que  todavía  no  se  ha  escrito  el 
código  fuente  que  hace  que  el  test  pase,  lo  correcto  es  que  el  test  falle,  ya  que  la  nueva 
característica  que  se  quiere  probar  todavía  no  está  implementada.  Este  paso  aumenta  la 
confianza  del  desarrollador  al  comprobar  que  el  test  prueba  una  característica  concreta 
del  código,  y  pasa  sólo  en  los  casos  previstos. 

3.  Escribir  el  código  fuente  que  haga  que  la  prueba  pase.  En  este  paso  se  persigue  im- 
plementar  el  código  fuente  necesario  para  que  el  test  pase.  El  código  generado  en  esta 
fase  no  tiene  que  ser  perfecto,  pues  el  objetivo  es  conseguir  que  el  test  pase  en  el  menor 
tiempo  posible. 

4.  Ejecutar  los  tests.  Si  todos  los  test  pasas,  se  corrobora  que  el  código  cumple  con  los 
requisitos  que  validan  las  pruebas,  además  de  asegurar  que  el  nuevo  código  fuente  no 
rompe  o  degrada  ninguna  de  las  características  previas  del  sistema  en  construcción.  Si 
algún  test  falla,  se  debe  corregir  el  código  fuente  recientemente  añadido. 
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5.  Refactorizar  el  código.  La  creciente  base  de  código  fuente  debe  ser  limpiada  regular¬ 
mente  durante  la  aplicación  de  TDD.  El  código  añadido  puede  ser  movido  a  otro  lugar 
mas  adecuado,  se  debe  eliminar  el  código  duplicado,  se  debe  renombrar  todas  las  cla¬ 
ses,  objetos,  variables,  módulos  y  métodos  cuyos  nombres  no  reflejen  claramente  su 
función.  En  este  paso  se  mejora  la  legibilidad  del  código  y  su  mantenibilidad,  lo  cuál 
aumenta  el  valor  del  código  fuente  a  lo  largo  de  su  ciclo  de  vida.  Al  reejecutar  los  test, 
se  asegura  que  el  proceso  de  refactorización  no  altera  la  funcionalidad  existente. 

Eliminar  código  duplicado  es  importante  en  el  proceso  de  desarrollo  de  software;  sin 
embargo,  en  este  caso  también  se  hace  referencia  al  código  duplicado  en  los  test,  de 
forma  que  también  se  pueden  reescribir,  fusionar  o  eliminar  test  siempre  que  se  con¬ 
serve  la  cobertura  de  código. 

6.  Repetir.  Comenzando  con  un  nuevo  test,  el  ciclo  se  repite  cada  vez  que  se  quiera  añadir 
una  nueva  funcionalidad.  Se  debe  intentar  añadir  funcionalidad  en  iteraciones  lo  mas 
pequeñas  posibles.  Si  el  código  añadido  no  satisface  un  nuevo  test  o  los  tests  anteriores 
comienzan  a  fallar  sin  razón  aparente,  es  una  buena  práctica  deshacer  los  cambios  en 
lugar  de  invertir  tiempo  en  un  proceso  de  depuración  lento  y  costoso.  Ea  integración 
continua  ayuda  aportando  un  punto  de  control  sobre  el  que  revertir  los  cambios.  Cuan¬ 
do  se  usan  bibliotecas  externas  es  importante  es  tan  importante  que  los  incrementos 
sean  lo  suficientemente  grandes  como  para  que  no  se  acabe  probando  la  bibblioteca,  a 
menos  que  se  sospeche  que  no  está  lo  suficientemente  probada  y  contenga  errores. 

6.2.4  Ventajas  de  aplicar  TDD 

A  raíz  de  lo  anterior,  se  deducen  una  serie  de  ventajas  que  aporta  TDD  como  metodología 
de  desarrollo: 

■  Cuando  se  escribe  el  código  antes  que  las  pruebas,  estas  suelen  estar  condicionadas  por 
la  funcionalidad  implementada,  con  lo  que  es  fácil  obviar  condiciones  en  las  pruebas. 
Realizando  el  proceso  a  la  inversa,  se  evita  este  problema. 

■  Al  realizar  primero  las  pruebas  se  realiza  un  ejercicio  previo  de  análisis  en  profun¬ 
didad  de  los  requisitos  y  de  los  diversos  escenarios.  Eliminando  la  mayor  parte  de 
variabilidad  y  encontrado  aquellos  aspectos  mas  importantes  o  no  contemplados  en 
los  requisitos. 

■  Debido  a  que  el  código  fuente  implementado  es  el  mínimo  imprescindible  que  cumpla 
la  condición  de  los  test,  se  reduce  la  redundancia  y  el  código  muerto. 

■  Una  correcta  refactorización  del  código  fuente  hace  que  este  sea  mas  legible,  óptimo 
y  fácil  de  mantener. 

■  Dado  que  el  código  evoluciona  con  el  paso  del  tiempo,  el  refactoring  debe  aplicarse, 
siempre  que  sea  necesario,  tanto  al  código  implementado  como  a  las  pruebas,  con 


133 


el  fin  de  mantenerlas  actualizadas,  añadiendo  nuevos  casos,  cuando  sea  necesario,  o 
completándolas  al  detectar  fallos  en  el  código. 

6.2.5  Dificultades  a  la  hora  de  emplear  TDD  en  el  desarrollo  de  un  videojue¬ 
go 

La  aplicación  de  TDD  a  cualquier  tipo  de  proyecto  requiere  un  esfuerzo  adicional,  ya 
que  el  desarrollador  debe  pensar  en  primer  lugar  qué  quiere  probar,  antes  de  pensar  cómo 
lo  va  a  desarrollar.  Además,  una  vez  que  sepa  qué  quiere  probar,  debe  pensar  cómo  va  a 
comprobar  que  el  software  que  se  está  probando  efectivamente  realiza  la  tarea  que  se  espera 
que  realice. 

Esto  es  especialmente  duro  cuando  dicho  proyecto  trata  de  desarrollar  un  videojuego,  ya 
que  comprobar  que  el  software  realiza  la  tarea  esperada  no  es  nada  sencillo.  Para  ilustrarlo, 
se  va  a  poner  un  ejemplo. 

En  un  videojuego  de  carreras,  sería  razonable  realizar  pruebas  de  sistema  que  comprueben 
si  la  lA  se  comporta  como  se  espera.  Por  un  lado,  dependiendo  del  tipo  de  videojuego  de 
carrera,  este  comportamiento  podría  variar  mucho.  Por  otro,  el  resultado  de  cada  uno  de  los 
pasos  que  aplica  el  algoritmo  de  lA  sobre  un  coche  se  ve  plasmado  en  forma  de  imágenes,  por 
lo  que  actualmente  no  es  posible  realizar  pruebas  directamente  sobre  las  imágenes  generadas 
en  un  tiempo  razonable  Es  cierto,  que  no  es  imposible  comprobar  una  serie  de  valores 
concretos  que  permitan  cercionarse  al  desarrollador  de  que  la  lA  se  comporta  de  acuerdo  a 
lo  que  él  esperaba. 

Por  otra  parte,  aunque  sea  posible  comprobar  que  lo  que  una  prueba  espera  está  sucedien¬ 
do  durante  la  ejecución  del  juego,  hay  que  señalar  que  los  videojuegos  abusan  de  cálculos 
en  coma  flotante.  Eos  resultados  de  dichos  cálculos  normalmente  cambian  dependiendo  del 
tipo  de  procesador  [Eie];  por  ejemplo,  el  juego  Battlezone  2  usa  un  modelo  de  red  (lockstep 
determinism  3.6.1  que  requería  que  los  cálculos  que  realizaran  los  clientes  fuesen  idénticos 
hasta  el  último  bit  de  la  mantisa  o  de  otro  modo  las  simulaciones  variaban.  Estas  desvia¬ 
ciones  de  los  cálculos,  (en  cosenos,  senos,  tangentes  y  sus  inversas),  eran  debidas  a  que  los 
procesadores  Intel  y  AMD  daban  resultados  diferentes  a  las  mismas  operaciones  aritméticas. 
Para  conseguir  que  los  resultados  no  variasen,  tuvieron  que  implementar  sus  propias  funcio¬ 
nes  aritméticas  para  garantizar  que  el  procesador  no  realizase  las  optimizaciones  producían 
dichas  variaciones  en  los  cálculos. 

Otro  punto  que  no  favorece  la  aplicación  de  TDD  a  un  videojuego  es  el  hecho  de  que  nor¬ 
malmente  durante  la  ejecución  del  mismo  hay  eventos  aleatorios,  que  tienen  como  función 
mejorar  la  experiencia  del  jugador;  por  ejemplo,  que  el  comportamiento  de  la  lA  no  sea  es¬ 
tático,  sino  que  se  adapte  a  las  circunstancias  de  la  partida.  Dado  que  dichos  eventos  no  se 

^E1  motivo  de  realizar  TDD  es  poder  tener  un  banco  de  pruebas  que  permitan  detectar  lo  antes  posibles 
problemas  en  el  software;  por  tanto,  es  importante  ejecutar  las  pruebas  lo  mas  a  menudo  posible 
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pueden  replicar  en  el  momento  en  el  que  se  desee,  probar  que  cuando  ocurren  el  videojuego 
se  comporta  como  se  espera  no  es  fácil,  ya  que  aunque  se  puede  provocar  que  sucedan  dichos 
eventos,  puede  que  el  resultado  no  sea  el  mismo. 

A  pesar  de  estas  dificultades,  las  ventajas  que  aporta  TDD  las  superan  ampliamente,  ya 
que  la  verdadera  dificultad  detrás  de  las  enumeradas  anteriormente  es  que  el  desarrollador 
tenga  la  madurez  suficiente  como  para  ser  capaz  de  superar  todas  estas  dificultades. 

6.3  Herramientas 

Debido  a  la  cantidad  de  problemas  que  se  han  resuelto  durante  la  realización  de  este  pro¬ 
yecto,  se  ha  tenido  que  integrar  una  gran  cantidad  de  herramientas,  que  han  ayudado  a  la 
resolución  de  dichos  problemas.  En  esta  sección  se  enumerarán  todas  esas  herramientas  dan¬ 
do  una  pequeña  descripción  sobre  ellas. 

6.3.1  Lenguajes  de  programación 

Se  han  utilizado  diferentes  lenguajes  de  programación  atendiendo  a  cuál  se  adaptaba  a  la 
hora  de  aportar  soluciones: 

Python  Lenguaje  de  alto  nivel,  interpretado  y  orientado  a  objetos.  Típicamente  utilizado 
como  lenguaje  de  prototipado,  se  ha  utilizado  para  la  creación  de  las  pruebas  de  inte¬ 
gración  del  proyecto. 

C++  Creado  por  Bjarne  Stroustrup  [Strl3],  C++  proporciona  mecanismos  de  orientación  a 
objetos  y  compatibilidad  con  C.  Es  un  lenguaje  compilado  que  ofrece  distintos  niveles 
de  abstracción  al  programador.  Debido  a  su  versatilidad  y  potencia,  es  el  lenguaje 
estándar  que  utiliza  la  industria  del  videojuego  y,  por  tanto,  requisito  del  proyecto. 

Bash  Boume  Again  Shell  (BASH)  [KoclO]  es  un  lenguaje  de  shell  utilizado  para  realizar 
diferentes  Scripts  con  el  fin  de  automatizar  tareas  relacionadas  con  la  instalación  del 
proyecto  y  la  compilación. 

XML  lenguaje  de  marcas  desarrollado  por  el  World  Wide  Web  Consortium  (W3C)  utilizado 
para  almacenar  datos  en  un  formato  inteligible.  Se  usa  para  definir  la  jerarquía  de  los 
elementos  de  la  interfaz  gráfica,  así  como  también  definir  las  propiedades  de  cada  uno 
de  los  widgets  utilizados. 

6.3.2  Control  de  versiones 

Para  el  desarrollo  del  proyecto,  se  ha  optado  por  usar  controles  de  versiones  para  gestionar 
de  forma  controlada  los  cambios  del  proyecto.  Este  tipo  de  software  ofrece  creación  de  ramas 
de  desarrollo,  que  es  una  forma  de  estructurar  las  versiones  del  proyecto,  lo  cuál  permite 
tener  una  versión  estable,  al  mismo  tiempo  que  se  sigue  desarrollando  nuevas  caracteristicas 
en  otras  ramas. 
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Git  Creado  por  Linus  Torbald  y  distribuido  bajo  licencia  GPL  v.2.  Es  sistema  de  control  de 
versiones  utilizado  para  gestionar  los  cambios  del  proyecto. 

6.3.3  Herramientas  de  desarrollo 

A  la  hora  de  desarrollar  el  proyecto  se  han  utilizado  una  serie  de  herramientas  tanto  para 

programar,  como  para  automatizar  el  proceso  de  compilación. 

Emacs  Editor  MACroS  (EMACS)  [Stal3]  editor  de  texto  utilizado  como  Integrated  Develop- 
ment  Environment  (IDE)  de  desarrollo  gracias  a  un  plugin  llamado  emacs-pills  [VA]. 

Blender  [Eou]  programa  de  modelado  y  creación  de  gráficos  tridimensionales  distribuido 
bajo  licencia  GPL.  Este  programa  se  ha  usado  para  crear  los  modelos  3D  usados  en  el 
juego,  realizar  el  mapeado  de  las  texturas  y  crear  animaciones  basadas  en  huesos. 

GIMP  Editor  de  imágenes  y  retoque  fotográfico.  Se  ha  utilizado  para  crear  elementos  del 
HUD. 

Make  [SM88]  Permite  la  compilación  automática  del  proyecto.  El  proceso  de  compila¬ 
ción  del  proyecto  está  desarrollado  con  esa  herramienta,  incluido  también  el  presente 
documento. 

Pkg-config  [Hen]  facilita  la  compilación  y  el  proceso  de  lineado  bilbiotecas.  Hace  uso 
de  unos  fichero  con  extensión  *.pc  donde  se  definen  los  directorios  de  cabeceras  y 
de  bibliotecas,  de  forma  que  ofrece  un  método  unificado  para  listar  las  dependencias 
necesarias  para  compilar  el  proyecto. 

GCC-4.9  [Plal3]  Compilador  de  GNU  para  los  lenguajes  C  y  C++. 

GDB  [SP14]  Depurador  para  el  compilador  de  GNU,  elegido  para  realizar  la  depuración  del 
código  fuente  programado  en  C-t-i-  de  forma  local  o  remota  cuando  sea  necesario. 

6.3.4  Bibliotecas  del  Motor  de  juego 

En  cuanto  al  motor  de  juegos  propio  que  ha  emergido  a  lo  largo  de  este  desarrollo,  a 

continuación  se  enumeran  las  bibliotecas  que  se  han  utilizado: 

Ogre3D  [ogr]  biblioteca  de  generación  de  gráficos  3D  de  propósito  general,  que  a  lo  largo 
de  los  años  ha  ido  cogiendo  fuerza  entre  la  comunidad  debido  a  que  se  distribuye  bajo 
licencia  MIT  y  a  la  potencia  que  ofrece.  Se  ha  utilizado  como  motor  de  renderizado, 
delegando  las  labores  de  gestión  de  la  escena,  tales  como  iluminación  y  sombreado 
dinámico,  gestión  de  las  mallas  3D  y  operaciones  geométricas  en  el  espacio  de  la 
escena. 

Bullet  Physics  [bule]  biblioteca  de  gestión  de  físicas  y  colisiones.  Multitud  de  proyectos 
comerciales,  como  Grand  ThefAuto  u  organizaciones  como  la  NASA  [bula]  hacen  uso 
de  esta  biblioteca,  razón  por  la  cuál  se  ha  delegado  toda  la  gestión  de  físicas  del  juego 
en  ella.  Ofrece  soporte  para  Windows,  Einux,  IOS  y  Android. 
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OIS  [Gam]  biblioteca  de  gestión  de  eventos  que  ofrece  soporte  para  Windows,  GNU/Linux, 
existiendo  un  port  de  esta  biblioteca  para  android  creado  por  la  comunidad  de  OgreSD. 

CEGUI  [cega]  biblioteca  de  gestión  de  widget  gráficos.  Se  ha  delegado  en  ella  la  gestión 
de  la  interfaz  gráfica,  creación  de  ventanas  y  menús. 

ZeroC  Ice  lCE[ICEb]  es  un  middleware  de  red  orientado  a  objetos.  Se  ha  utilizado  debido  a 
que  facilita  enormemente  la  programación  en  red,  además  de  que  añade  una  sobrecarga 
mínima  a  las  comunicaciones. 

SDL  SDL  es  un  conjunto  de  bibliotecas  desarrolladas  en  lenguaje  C  que  ofrece  operaciones 
bácisa  de  dibujo  en  2D,  gestión  de  efectos  de  sonido  y  música,  además  de  carga  y 
gestión  de  elementos  multimedia. 

Boost  es  un  conjunto  de  bibliotecas  de  software  libre  preparadas  para  extender  las  capa¬ 
cidades  del  lenguaje  de  programación  C-i-i-,  distribuido  bajo  licencia  BSD.  Gran  par¬ 
te  de  las  características  que  ofrecen  este  conjunto  de  bibliotecas  han  sido  absorbi¬ 
das  por  la  biblioteca  estándar  de  C-i-i-.  En  este  proyecto  se  ha  usado  la  biblioteca  de 
Eogs(Boost.Eog). 


6.3.5  Documentación 

Ea  realización  de  documentación  se  ha  llevado  a  cabo  utilizando  tanto  herramientas  de  ma- 

quetación  de  textos  como  herramientas  que  permitan  hacer  diagramas  para  ilustrar  y  facilitar 

la  comprensión  del  proyecto. 

GIMP  Editor  de  imágenes  y  retoque  fotográfico.  Utilizado  en  la  maquetación  de  fotografías 
e  ilustraciones. 

Inkscape  Editor  de  imágenes  vectorial. 

Libreoffice  Impress  Programa  para  la  realización  de  presentaciones,  utilizado  en  algunas 
de  las  presentaciones  que  se  han  realizado  de  este  proyecto. 

Dia  Editor  de  diagramas.  Utilizado  para  construir  los  diagramas  que  se  han  utilizado  para  el 
desarrollo  del  proyecto. 

DTeX  Eenguaje  de  maquetación  de  textos,  utilizado  para  la  elaboración  del  presente  docu¬ 
mento  y  algunas  presentaciones. 

noweb  Herramienta  de  programación  literal  utilizada  durante  algunas  de  las  iteraciones. 

arco-pfc  Plantilla  de  ET^utilizada  en  la  documentación  de  este  proyecto. 


137 


Capítulo  7 


Conclusiones  y  trabajo  futuro 


En  este  eapítulo  se  presentan  los  objetivos  eumplidos  durante  el  desarrollo  del  proyee- 
to.  Por  otra  parte,  se  expondrán  las  impresiones  personales  que  se  han  tenido  desde 
el  eomienzo  hasta  la  finalizaeión  del  mismo,  así  eomo  una  serie  de  propuestas  de  trabajo 
futuro. 

7.0.6  Conclusiones 

A  lo  largo  del  transeurso  del  presente  proyeeto,  se  han  eumplido  los  siguientes  objeti¬ 
vos: 


■  Desarrollo  de  un  videojuego  3D  eon  las  siguientes  funeionalidades: 

•  Inteligeneia  artifieial  que  permite  que  el  jugador  eompita  eontra  la  máquina.  Se 
ha  desarrollado  un  algoritmo  basado  en  reglas,  que  permite  adaptarse  a  los  ele¬ 
mentos  dinámieos  que  pueda  eneontrar  la  máquina  durante  el  desarrollo  de  una 
earrera.  En  espeeial,  ha  sido  posible  erear  un  soporte  para  integrar  la  lA  dentro  del 
juego,  implementado  de  tal  forma  que  es  seneillo  modifiear  el  algoritmo  existente 
o  añadir  uno  nuevo. 

•  Módulo  de  gestión  de  red.  Se  ha  implementado  satisfaetoriamente  un  modelo  de 
red  que  permite  jugar  en  red  loeal.  A  la  hora  de  jugar  en  Internet,  se  ha  eonsegui- 
do  que  el  juego  funeione  siempre  y  euando  la  lateneia  del  eliente  oseile  entorno  a 
los  lOOms  y  exista  una  pérdida  de  paquetes  inferior  al  10  %.  En  eonexiones  eon 
mayores  lateneias  o  pérdida  de  paquetes  superiores,  la  experieneia  de  usuario  se 
deteriora  en  relación  al  aumento  de  pérdida  de  paquetes  y  lateneia.  Al  alcanzar 
los  300  ms  de  lateneia  comienza  a  dificultarse  la  labor  de  sincronización  de  los 
clientes  y  con  una  pérdida  de  paquetes  del  30  %  los  coches  de  los  jugadores  re¬ 
motos  dan  saltos  constantemente  en  el  momento  en  que  se  sincroniza  la  posición 
del  cliente  con  la  que  le  corresponde. 

•  Creación  de  circuitos  escriptable,  basada  en  un  formato  de  fichero  que  permite 
una  representación  gráfica  del  mismo. 

■  Instrumentación  del  videojuego.  Gracias  a  esto  se  ha  podido  crear  una  serie  de  pruebas 
automáticas  que  sirven  como  ejemplo  para  mostrar  hasta  qué  punto  es  posible  aplicar 
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técnicas  de  testing.  Esto  es  algo  que  se  ha  considerado  muy  innovador,  automático  al 
desarrollo  de  un  videojuego.  Con  estas  pruebas  se  ha  optimizado  la  lA,  demostrando 
que  es  posible  realizar  pruebas  automáticas  en  entornos  complejos. 

■  Como  resultado  del  desarrollo  ha  emergido  lo  que  en  un  futuro  podría  ser  un  motor  de 
juegos  propio.  Se  ha  invertido  esfuerzo  en  utilizar  el  estándar  C++11,  así  como  todas 
las  características  que  este  aporta:  funciones  lambda,  deducción  automática  de  tipos 
con  la  sentencia  auto,  múltiples  algoritmos  de  ordenación  y  búsqueda  en  contenedo¬ 
res,  adaptadores  de  función  (función  bind),  etcétera.  Se  ha  hecho  énfasis  en  diseñar 
una  arquitectura  flexible  y  mantenible,  desacoplando  la  lógica  de  control  de  las  clases 
que  almacenan  información,  buscando  en  todo  momento,  y  siempre  dentro  de  las  limi¬ 
taciones  del  proyectando,  hacer  un  código  lo  más  legible  y  limpio  posible  que  pueda 
servir  como  ejemplo  de  buenas  prácticas. 

7.0.7  Mejoras  y  trabajo  futuro 

A  continuación  se  ofrecen  algunas  de  las  posibles  opciones  de  trabajo  futuro  para  este 
proyecto,  las  cuales  que  quedan  fuera  del  alcande  del  mismo: 

■  Mejorar  el  modulo  de  red  para  poder  jugar  en  Internet,  no  solo  en  condiciones  de  red 
óptimas,  implementando  alguna  solución  de  compensación  de  latencia  mas  sofisticada. 

■  Desacoplar  la  lógica  del  videojuego  completamente  del  motor  de  juego,  de  forma  que 
se  pueda  utilizar  para  crear  cualquier  tipo  de  videojuego;  es  decir,  hacer  una  libería 
genérica. 

■  Hacer  mas  genérico  el  controlador  de  jugador  destinado  a  la  lA,  de  forma  que  sea 
posible  cargar  cualquier  tipo  de  Agente. 

■  Añadir  un  modo  de  depuración  gráfico,  de  forma  que  al  pinchar  sobre  un  objeto  de  la 
escena  del  videojuego  se  muestre  por  pantalla  el  estado  de  dicho  objeto:  nombre,  tipo, 
métodos  de  la  clase,  valor  de  las  variables  de  clase,  etcétera. 
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Anexo  A 


Manual  de  usuario.  Instalación  del  juego 


En  este  manual  se  explica  el  proceso  de  instalación  del  videojuego  en  un  sistema  GNU/- 
Linux. 

En  el  proyecto  se  proporciona  un  script  de  instalación,  el  cuál  realiza  el  proceso  de  ins¬ 
talación  de  las  dependencias  del  proyecto,  tras  lo  cuál  prosigue  compilando  y  generando  un 
binario  del  juego. 

Para  instalar  comenzar  con  la  instalación,  el  primer  paso  consiste  en  descargar  el  proyecto 
del  repositorio.  Para  ello,  hay  que  ejecutar  el  comando  del  listado  A.l: 


git  clone  git(abitbucket.org:arco_group/tfg.tinman.git 

Listado  A.l:  Descargar  el  repositorio. 

El  comando  anterior  creará  una  carpeta  que  contendrá  el  proyecto  completo.  A  continua¬ 
ción,  hay  que  dirigirse  a  la  carpeta  útil  y  ejecutar  el  script  tinman-installer.bash,  tal  como  se 
ve  en  el  listado  A. 2.  En  el  listado  A. 3  se  muestra  dicho  script. 


cd  Util;  ./tinman-installer.bash 

Listado  A. 2:  Ejecución  del  script  de  instalación  de  dependencias. 

Por  orden,  se  instala  pkg-config,  una  herramienta  que  se  utiliza  en  este  proyecto  para  sim¬ 
plificar  la  tarea  de  compilación  y  lineado  de  bibliotecas.  Después  se  instalan  las  bibliotecas 
principales  del  proyecto: 

■  OIS,  que  se  encarga  de  la  gestión  de  eventos  de  teclado, 

■  OgreSD,  encargado  de  la  gestión  de  los  gráficos  3D, 

■  Bullet  Physics,  biblioteca  de  gestión  de  físicas  y  colisiones, 

■  Boost,  que  se  usa  como  sistema  de  logs, 

■  SDL,  que  usa  para  la  gestión  de  efectos  de  sonidos, 

■  ZeroC  ICE,  middleware  de  red  usado  para  la  gestión  de  las  comunicaciones  del  modo 
de  juego  multijugador. 
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■  CEGUI,  biblioteca  en  la  que  se  delega  la  gestión  de  los  elementos  de  la  interfaz  gráfica. 

Completado  el  proceso  de  instalación  de  las  dependencias,  el  script  prosigue  con  la  com¬ 
pilación  del  proyecto,  que  dará  como  resultado  un  binario,  el  cuál  al  ser  ejecutado(bien  con 
doble  click  del  ratón  o  desde  el  terminal)  lanzará  una  instancia  del  juego.  De  este  último 
punto  se  puede  señalar  que  el  programa  Make  ofrece  la  posibilidad  de  paralelizar  las  tareas 
que  se  le  encomiendan  a  través  del  uso  de  workers.  Haciendo  uso  del  ílag  -j  <número>,  ma¬ 
ke  ejecutará  en  paralelo  aquellas  tareas  que  no  tengan  dependencias  entre  ellas.  Dado  que  el 
proyecto  cuenta  con  algo  mas  de  30  ficheros  de  C++,  esto  agiliza  en  gran  medida  el  proce¬ 
so  de  compilación.  En  el  script  se  indica  que  se  lancen  tantos  workers  como  núcleos  tiene 
el  procesador  de  la  máquina  donde  se  esté  ejecutando,  para  lo  cuál  se  ejecuta  el  programa 
nproc,  que  devuelve  un  entero  que  indica  el  número  de  núcleos. 


#  coding : utf -8;  tab-width:4;  mode: Shell -script 
#install  Utils 

sudo  apt-get  -y  install  pkg-config; 

#install  OIS 

sudo  apt-get  -y  install  libois-1.3.0  libois-dev; 

#install  0gre3D 

sudo  apt-get  -y  install  libogre-1.8.0  libogre-1.8-dev; 

#install  Bullet 

sudo  apt-get  -y  install  libbullet-dev  libbullet2 . 82-dbg  libbullet-extras-dev; 

#install  Boost 

sudo  apt-get  -y  install  libboostl.55-all-dev 
#install  SDL 

sudo  apt-get  -y  install  libsdll . 2-dev  libsdl-imagel.2-dev  libsdl-soundl.2-dev  libsdl-iriixerl.2-dev 
libsdl-ttf2.0-dev 

#install  ZeroC  Ice 

sudo  apt-get  install  zeroc-ice35 

#install  CEGUI 
./cegui-installer. bash; 

cd  ../src/;  make  -j$(nproc) 


Eistado  A. 3:  Script  de  instalación. 
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Anexo  B 


GNU  Free  Documentation  License 


Versión  1.3,  3  November  2008 

Copyright  ©  2000,  2001,  2002,  2007,  2008  Free  Software  Foundation,  Inc.  <http://fsf.org/> 

Everyone  is  permitted  to  copy  and  distribute  verbatim  copies  of  this  license  document,  but  changing  it  is  not  allowed. 


0.  PREAMBLE 

The  purpose  of  this  License  is  to  make  a  manual,  textbook,  or  other  functional  and  useful  document  “free”  in  the  sense  of  freedom:  to 
assure  everyone  the  effective  freedom  to  copy  and  redistribute  it,  with  or  without  modifying  it,  either  commercially  or  noncommercially. 
Secondarily,  this  License  preserves  for  the  author  and  publisher  a  way  to  get  credit  for  their  work,  while  not  being  considered  responsible 
for  modifications  made  by  others. 

This  License  is  a  kind  of  “copyleft”,  which  means  that  derivativo  works  of  the  document  must  themselves  be  free  in  the  same  sense.  It 
complements  the  GNU  General  Public  License,  which  is  a  copyleft  license  designed  for  free  software. 

We  have  designed  this  License  in  order  to  use  it  for  manuals  for  free  software,  because  free  software  needs  free  documentation:  a 
free  program  should  come  with  manuals  providing  the  same  freedoms  that  the  software  does.  But  this  License  is  not  limited  to  software 
manuals;  it  can  be  used  for  any  textual  work,  regardless  of  subject  matter  or  whether  it  is  published  as  a  printed  book.  We  recommend  this 
License  principally  for  works  whose  purpose  is  instruction  or  reference. 


1.  APPLICABILITY  AND  DEFINITIONS 

This  License  applies  to  any  manual  or  other  work,  in  any  médium,  that  contains  a  notice  placed  by  the  copyright  holder  saying  it  can  be 
distributed  under  the  terms  of  this  License.  Such  a  notice  grants  a  world-wide,  royalty-free  license,  unlimited  in  duration,  to  use  that  work 
under  the  conditions  stated  herein.  The  “Document”,  below,  refers  to  any  such  manual  or  work.  Any  member  of  the  public  is  a  licensee, 
and  is  addressed  as  “you”.  You  accept  the  license  if  you  copy,  modify  or  distribute  the  work  in  a  way  requiring  permission  under  copyright 
law. 

A  “Modified  Versión”  of  the  Document  means  any  work  containing  the  Document  or  a  portion  of  it,  either  copied  verbatim,  or  with 
modifications  and/or  translated  into  another  language. 

A  “Secondary  Section”  is  a  named  appendix  or  a  front-matter  section  of  the  Document  that  deais  exclusively  with  the  relationship  of 
the  publishers  or  authors  of  the  Document  to  the  Document’s  overall  subject  (or  to  related  matters)  and  contains  nothing  that  could  fall 
directly  within  that  overall  subject.  (Thus,  if  the  Document  is  in  part  a  textbook  of  mathematics,  a  Secondary  Section  may  not  explain  any 
mathematics.)  The  relationship  could  be  a  matter  of  historical  connection  with  the  subject  or  with  related  matters,  or  of  legal,  commercial, 
philosophical,  ethical  or  political  position  regarding  them. 

The  “Invariant  Sections”  are  certain  Secondary  Sections  whose  titles  are  designated,  as  being  those  of  Invariant  Sections,  in  the  notice 
that  says  that  the  Document  is  released  under  this  License.  If  a  section  does  not  fit  the  above  definition  of  Secondary  then  it  is  not  allowed 
to  be  designated  as  Invariant.  The  Document  may  contain  zero  Invariant  Sections.  If  the  Document  does  not  identify  any  Invariant  Sections 
then  there  are  none. 

The  “Cover  Texts”  are  certain  short  passages  of  text  that  are  listed,  as  Front-Cover  Texts  or  Back-Cover  Texts,  in  the  notice  that  says 
that  the  Document  is  released  under  this  License.  A  Front-Cover  Text  may  be  at  most  5  words,  and  a  Back-Cover  Text  may  be  at  most  25 
words. 
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A  “Transparent”  copy  of  the  Document  means  a  machine-readable  copy,  represented  in  a  format  whose  specification  is  available  to  the 
general  public,  that  is  suitable  for  revising  the  document  straightforwardly  with  generic  text  editors  or  (for  images  composed  of  pixels) 
generic  paint  programs  or  (for  drawings)  some  widely  available  drawing  editor,  and  that  is  suitable  for  input  to  text  formatters  or  for 
automatic  translation  to  a  variety  of  formats  suitable  for  input  to  text  formatters.  A  copy  made  in  an  otherwise  Transparent  file  format 
whose  markup,  or  absence  of  markup,  has  been  arranged  to  thwart  or  discourage  subsequent  modification  by  readers  is  not  Transparent. 
An  image  format  is  not  Transparent  if  used  for  any  substantial  amount  of  text.  A  copy  that  is  not  “Transparent”  is  called  “Opaque”. 

Examples  of  suitable  formats  for  Transparent  copies  inelude  plain  ASCII  without  markup,  Texinfo  input  format,  LaTeX  input  format, 
SGML  or  XML  using  a  publicly  available  DTD,  and  standard-conforming  simple  HTML,  PostScript  or  PDF  designed  for  human  modifi¬ 
cation.  Examples  of  transparent  image  formats  inelude  PNG,  XCF  and  JPG.  Opaque  formats  inelude  proprietary  formats  that  can  be  read 
and  edited  only  by  proprietary  word  processors,  SGML  or  XML  for  which  the  DTD  and/or  processing  tools  are  not  generally  available, 
and  the  machine-generated  HTML,  PostScript  or  PDF  produced  by  some  word  processors  for  output  purposes  only. 

The  “Title  Page”  means,  for  a  printed  book,  the  title  page  itself,  plus  such  following  pages  as  are  needed  to  hold,  legibly,  the  material 
this  License  requires  to  appear  in  the  title  page.  For  works  in  formats  which  do  not  have  any  title  page  as  such,  “Title  Page”  means  the  text 
near  the  most  prominent  appearance  of  the  work’s  title,  preceding  the  beginning  of  the  body  of  the  text. 

The  “publisher”  means  any  person  or  entity  that  distributes  copies  of  the  Document  to  the  public. 


A  section  “Entitled  XYZ”  means  a  named  subunit  of  the  Document  whose  title  either  is  precisely  XYZ  or  contains  XYZ  in  parentheses 
following  text  that  translates  XYZ  in  another  language.  (Here  XYZ  stands  for  a  specific  section  ñame  mentioned  below,  such  as  “Acknow- 
ledgements”,  “Dedications”,  “Endorsements”,  or  “History”.)  To  “Preserve  the  Title”  of  such  a  section  when  you  modify  the  Document 
means  that  it  remains  a  section  “Entitled  XYZ”  according  to  this  definition. 


The  Document  may  inelude  Warranty  Disclaimers  next  to  the  notice  which  States  that  this  License  applies  to  the  Document.  These 
Warranty  Disclaimers  are  considered  to  be  included  by  reference  in  this  License,  but  only  as  regards  disclaiming  warranties:  any  other 
implication  that  these  Warranty  Disclaimers  may  have  is  void  and  has  no  effect  on  the  meaning  of  this  License. 


2.  VERBATIM  COPYING 

You  may  copy  and  distribute  the  Document  in  any  médium,  either  commercially  or  noncommercially,  provided  that  this  License,  the 
copyright  notices,  and  the  license  notice  saying  this  License  applies  to  the  Document  are  reproduced  in  all  copies,  and  that  you  add  no  other 
conditions  whatsoever  to  those  of  this  License.  You  may  not  use  technical  measures  to  obstruct  or  control  the  reading  or  further  copying  of 
the  copies  you  make  or  distribute.  However,  you  may  accept  compensation  in  exchange  for  copies.  If  you  distribute  a  large  enough  number 
of  copies  you  must  also  follow  the  conditions  in  section  3. 

You  may  also  lend  copies,  under  the  same  conditions  stated  above,  and  you  may  publicly  display  copies. 


3.  COPYING  IN  QUANTITY 


If  you  publish  printed  copies  (or  copies  in  media  that  commonly  have  printed  covers)  of  the  Document,  numbering  more  than  100,  and 
the  Document’s  license  notice  requires  Cover  Texts,  you  must  endose  the  copies  in  covers  that  carry,  clearly  and  legibly,  all  these  Cover 
Texts:  Front-Cover  Texts  on  the  front  cover,  and  Back-Cover  Texts  on  the  back  cover.  Both  covers  must  also  clearly  and  legibly  identify 
you  as  the  publisher  of  these  copies.  The  front  cover  must  present  the  full  title  with  all  words  of  the  title  equally  prominent  and  visible. 
You  may  add  other  material  on  the  covers  in  addition.  Copying  with  changes  limited  to  the  covers,  as  long  as  they  preserve  the  title  of  the 
Document  and  satisfy  these  conditions,  can  be  treated  as  verbatim  copying  in  other  respeets. 

If  the  required  texts  for  either  cover  are  too  voluminous  to  fit  legibly,  you  should  put  the  first  ones  listed  (as  many  as  fit  reasonably)  on 
the  actual  cover,  and  continué  the  rest  onto  adjacent  pages. 

If  you  publish  or  distribute  Opaque  copies  of  the  Document  numbering  more  than  100,  you  must  either  inelude  a  machine-readable 
Transparent  copy  along  with  each  Opaque  copy,  or  State  in  or  with  each  Opaque  copy  a  computer-network  location  from  which  the  general 
network-using  public  has  access  to  download  using  public-standard  network  protocols  a  complete  Transparent  copy  of  the  Document,  free 
of  added  material.  If  you  use  the  latter  option,  you  must  take  reasonably  prudent  steps,  when  you  begin  distribution  of  Opaque  copies  in 
quantity,  to  ensure  that  this  Transparent  copy  will  remain  thus  accessible  at  the  stated  location  until  at  least  one  year  after  the  last  time  you 
distribute  an  Opaque  copy  (directly  or  through  your  agents  or  retailers)  of  that  edition  to  the  public. 

It  is  requested,  but  not  required,  that  you  contact  the  authors  of  the  Document  well  before  redistributing  any  large  number  of  copies,  to 
give  them  a  chance  to  provide  you  with  an  updated  versión  of  the  Document. 
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4.  MODIFICATIONS 


You  may  copy  and  distribute  a  Modified  Versión  of  the  Document  under  the  conditions  of  sections  2  and  3  above,  provided  that  you 
release  the  Modified  Versión  under  precisely  this  License,  with  the  Modified  Versión  filling  the  role  of  the  Document,  thus  licensing 
distribution  and  modification  of  the  Modified  Versión  to  whoever  possesses  a  copy  of  it.  In  addition,  you  must  do  these  things  in  the 
Modified  Versión: 

■  A.  Use  in  the  Title  Page  (and  on  the  covers,  if  any)  a  title  distinct  from  that  of  the  Document,  and  from  those  of  previous  versions 
(which  should,  if  there  were  any,  be  Usted  in  the  History  section  of  the  Document).  You  may  use  the  same  title  as  a  previous 
versión  if  the  original  publisher  of  that  versión  gives  permission. 

■  B.  List  on  the  Title  Page,  as  authors,  one  or  more  persons  or  entities  responsible  for  authorship  of  the  modifications  in  the  Modified 
Versión,  together  with  at  least  five  of  the  principal  authors  of  the  Document  (all  of  its  principal  authors,  if  it  has  fewer  than  five), 
unless  they  release  you  from  this  requirement. 

■  C.  State  on  the  Title  page  the  ñame  of  the  publisher  of  the  Modified  Versión,  as  the  publisher. 

■  D.  Preserve  all  the  copyright  notices  of  the  Document. 

■  E.  Add  an  appropriate  copyright  notice  for  your  modifications  adjacent  to  the  other  copyright  notices. 

■  F.  Inelude,  immediately  after  the  copyright  notices,  a  license  notice  giving  the  public  permission  to  use  the  Modified  Versión 
under  the  terms  of  this  License,  in  the  form  shown  in  the  Addendum  below. 

■  G.  Preserve  in  that  license  notice  the  full  lists  of  Invariant  Sections  and  required  Cover  Texts  given  in  the  Document’s  license 
notice. 

■  H.  Inelude  an  unaltered  copy  of  this  License. 

■  I.  Preserve  the  section  Entitled  “History”,  Preserve  its  Title,  and  add  to  it  an  item  stating  at  least  the  title,  year,  new  authors,  and 
publisher  of  the  Modified  Versión  as  given  on  the  Title  Page.  If  there  is  no  section  Entitled  “History”  in  the  Document,  create  one 
stating  the  title,  year,  authors,  and  publisher  of  the  Document  as  given  on  its  Title  Page,  then  add  an  item  describing  the  Modified 
Versión  as  stated  in  the  previous  sentence. 

■  J.  Preserve  the  network  location,  if  any,  given  in  the  Document  for  public  access  to  a  Transparent  copy  of  the  Document,  and 
likewise  the  network  locations  given  in  the  Document  for  previous  versions  it  was  based  on.  These  may  be  placed  in  the  “History” 
section.  You  may  omit  a  network  location  for  a  work  that  was  published  at  least  four  years  before  the  Document  itself,  or  if  the 
original  publisher  of  the  versión  it  refers  to  gives  permission. 

■  K.  For  any  section  Entitled  “Acknowledgements”  or  “Dedications”,  Preserve  the  Title  of  the  section,  and  preserve  in  the  section 
all  the  substance  and  tone  of  each  of  the  contributor  acknowledgements  and/or  dedications  given  therein. 

■  L.  Preserve  all  the  Invariant  Sections  of  the  Document,  unaltered  in  their  text  and  in  their  titles.  Section  numbers  or  the  equivalent 
are  not  considered  part  of  the  section  titles. 

■  M.  Delete  any  section  Entitled  “Endorsements”.  Such  a  section  may  not  be  included  in  the  Modified  Versión. 

■  N.  Do  not  retitle  any  existing  section  to  be  Entitled  “Endorsements”  or  to  conflict  in  title  with  any  Invariant  Section. 

■  O.  Preserve  any  Warranty  Disclaimers. 

If  the  Modified  Versión  ineludes  new  front-matter  sections  or  appendices  that  qualify  as  Secondary  Sections  and  contain  no  material 
copied  from  the  Document,  you  may  at  your  option  desígnate  some  or  all  of  these  sections  as  invariant.  To  do  this,  add  their  titles  to  the 
list  of  Invariant  Sections  in  the  Modified  Version’s  license  notice.  These  titles  must  be  distinct  from  any  other  section  titles. 

You  may  add  a  section  Entitled  “Endorsements”,  provided  it  contains  nothing  but  endorsements  of  your  Modified  Versión  by  various 
parties — for  example,  statements  of  peer  review  or  that  the  text  has  been  approved  by  an  organization  as  the  authoritative  definition  of  a 
standard. 

You  may  add  a  passage  of  up  to  five  words  as  a  Front-Cover  Text,  and  a  passage  of  up  to  25  words  as  a  Back-Cover  Text,  to  the  end 
of  the  list  of  Cover  Texts  in  the  Modified  Versión.  Only  one  passage  of  Front-Cover  Text  and  one  of  Back-Cover  Text  may  be  added  by 
(or  through  arrangements  made  by)  any  one  entity.  If  the  Document  already  ineludes  a  cover  text  for  the  same  cover,  previously  added  by 
you  or  by  arrangement  made  by  the  same  entity  you  are  acting  on  behalf  of,  you  may  not  add  another;  but  you  may  replace  the  oíd  one,  on 
explicit  permission  from  the  previous  publisher  that  added  the  oíd  one. 

The  author(s)  and  publisher(s)  of  the  Document  do  not  by  this  License  give  permission  to  use  their  ñames  for  publicity  for  or  to  assert 
or  imply  endorsement  of  any  Modified  Versión.  5.  COMBINING  DOCUMENTS 

You  may  combine  the  Document  with  other  documents  released  under  this  License,  under  the  terms  defined  in  section  4  above  for 
modified  versions,  provided  that  you  inelude  in  the  combination  all  of  the  Invariant  Sections  of  all  of  the  original  documents,  unmodified, 
and  list  them  all  as  Invariant  Sections  of  your  combined  work  in  its  license  notice,  and  that  you  preserve  all  their  Warranty  Disclaimers. 
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The  combined  work  need  only  contain  one  copy  of  this  License,  and  múltiple  identical  Invariant  Sections  may  be  replaced  with  a  single 
copy.  If  there  are  múltiple  Invariant  Sections  with  the  same  ñame  but  different  contents,  make  the  title  of  each  such  section  unique  by 
adding  at  the  end  of  it,  in  parentheses,  the  ñame  of  the  original  author  or  publisher  of  that  section  if  known,  or  else  a  unique  number.  Make 
the  same  adjustment  to  the  section  titles  in  the  list  of  Invariant  Sections  in  the  license  notice  of  the  combined  work. 

In  the  combination,  you  must  combine  any  sections  Entitled  “History”  in  the  various  original  documents,  forming  one  section  Entitled 
“History”;  likewise  combine  any  sections  Entitled  “Acknowledgements”,  and  any  sections  Entitled  “Dedications”.  You  must  delete  all 
sections  Entitled  “Endorsements”. 


5.  COLLECTIONS  OF  DOCUMENTS 

You  may  make  a  collection  consisting  of  the  Document  and  other  documents  released  under  this  License,  and  replace  the  individual 
copies  of  this  License  in  the  various  documents  with  a  single  copy  that  is  included  in  the  collection,  provided  that  you  follow  the  rules  of 
this  License  for  verbatim  copying  of  each  of  the  documents  in  all  other  respects. 

You  may  extract  a  single  document  from  such  a  collection,  and  distribute  it  individually  under  this  License,  provided  you  insert  a  copy 
of  this  License  into  the  extracted  document,  and  follow  this  License  in  all  other  respects  regarding  verbatim  copying  of  that  document. 


6.  AGGREGATION  WITH  INDEPENDENT  WORKS 

A  compilation  of  the  Document  or  its  derivativos  with  other  sepárate  and  independent  documents  or  works,  in  or  on  a  volume  of  a 
storage  or  distribution  médium,  is  called  an  “aggregate”  if  the  copyright  resulting  from  the  compilation  is  not  used  to  limit  the  legal  rights 
of  the  compilation’s  users  beyond  what  the  individual  works  permit.  When  the  Document  is  included  in  an  aggregate,  this  License  does 
not  apply  to  the  other  works  in  the  aggregate  which  are  not  themselves  derivativo  works  of  the  Document. 

If  the  Cover  Text  requirement  of  section  3  is  applicable  to  these  copies  of  the  Document,  then  if  the  Document  is  less  than  one  half 
of  the  entire  aggregate,  the  Document’s  Cover  Texts  may  be  placed  on  covers  that  bracket  the  Document  within  the  aggregate,  or  the 
electronic  equivalent  of  covers  if  the  Document  is  in  electronic  form.  Otherwise  they  must  appear  on  printed  covers  that  bracket  the  whole 
aggregate. 


7.  TRANSLATION 

Translation  is  considered  a  kind  of  modification,  so  you  may  distribute  translations  of  the  Document  under  the  terms  of  section  4. 
Replacing  Invariant  Sections  with  translations  requires  special  permission  from  their  copyright  holders,  but  you  may  inelude  translations 
of  some  or  all  Invariant  Sections  in  addition  to  the  original  versions  of  these  Invariant  Sections.  You  may  inelude  a  translation  of  this 
License,  and  all  the  license  notices  in  the  Document,  and  any  Warranty  Disclaimers,  provided  that  you  also  inelude  the  original  English 
versión  of  this  License  and  the  original  versions  of  those  notices  and  disclaimers.  In  case  of  a  disagreement  between  the  translation  and  the 
original  versión  of  this  License  or  a  notice  or  disclaimer,  the  original  versión  will  prevail. 

If  a  section  in  the  Document  is  Entitled  “Acknowledgements”,  “Dedications”,  or  “History”,  the  requirement  (section  4)  to  Preserve  its 
Title  (section  1)  will  typically  require  changing  the  actual  title. 


8.  TERMINATION 

You  may  not  copy,  modify,  sublicense,  or  distribute  the  Document  except  as  expressly  provided  under  this  License.  Any  attempt 
otherwise  to  copy,  modify,  sublicense,  or  distribute  it  is  void,  and  will  automatically  termínate  your  rights  under  this  License. 

However,  if  you  cease  all  violation  of  this  License,  then  your  license  from  a  particular  copyright  holder  is  reinstated  (a)  provisionally, 
unless  and  until  the  copyright  holder  explicitly  and  finally  terminates  your  license,  and  (b)  permanently,  if  the  copyright  holder  fails  to 
notify  you  of  the  violation  by  some  reasonable  means  prior  to  60  days  after  the  cessation. 

Moreover,  your  license  from  a  particular  copyright  holder  is  reinstated  permanently  if  the  copyright  holder  notifies  you  of  the  violation 
by  some  reasonable  means,  this  is  the  first  time  you  have  received  notice  of  violation  of  this  License  (for  any  work)  from  that  copyright 
holder,  and  you  cure  the  violation  prior  to  30  days  after  your  receipt  of  the  notice. 

Termination  of  your  rights  under  this  section  does  not  termínate  the  licenses  of  parties  who  have  received  copies  or  rights  from  you 
under  this  License.  If  your  rights  have  been  terminated  and  not  permanently  reinstated,  receipt  of  a  copy  of  some  or  all  of  the  same  material 
does  not  give  you  any  rights  to  use  it. 
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9.  FUTURE  REVISIONS  OF  THIS  FICENSE 


The  Free  Software  Foundation  may  publish  new,  revised  versions  of  the  GNU  Free  Documentation  License  from  time  to  time. 
Such  new  versions  will  be  similar  in  spirit  to  the  present  versión,  but  may  differ  in  detail  to  address  new  problems  or  concems.  See 
http://www.gnu.org/copyleft/. 

Each  versión  of  the  License  is  given  a  distinguishing  versión  number.  If  the  Document  specifies  that  a  particular  numbered  versión  of 
this  License  “or  any  later  versión”  applies  to  it,  you  have  the  option  of  following  the  terms  and  conditions  either  of  that  specified  versión 
or  of  any  later  versión  that  has  been  published  (not  as  a  draft)  by  the  Free  Software  Foundation.  If  the  Document  does  not  specify  a  versión 
number  of  this  License,  you  may  choose  any  versión  ever  published  (not  as  a  draft)  by  the  Free  Software  Foundation.  If  the  Document 
specifies  that  a  proxy  can  decide  which  future  versions  of  this  License  can  be  used,  that  proxy’s  public  statement  of  acceptance  of  a  versión 
permanently  authorizes  you  to  choose  that  versión  for  the  Document. 


10.  RELICENSING 

“Massive  Multiauthor  Collaboration  Site”  (or  “MMC  Site”)  means  any  World  Wide  Web  server  that  publishes  copyrightable  works  and 
also  provides  prominent  facilities  for  anybody  to  edit  those  works.  A  public  wiki  that  anybody  can  edit  is  an  example  of  such  a  server.  A 
“Massive  Multiauthor  Collaboration”  (or  “MMC”)  contained  in  the  site  means  any  set  of  copyrightable  works  thus  published  on  the  MMC 
site. 

“CC-BY-SA”  means  the  Creative  Commons  Attribution-Share  Alike  3.0  license  published  by  Creative  Commons  Corporation,  a  not- 
for-profit  Corporation  with  a  principal  place  of  business  in  San  Francisco,  California,  as  well  as  future  copyleft  versions  of  that  license 
published  by  that  same  organization. 

“Incorpórate”  means  to  publish  or  republish  a  Document,  in  whole  or  in  part,  as  part  of  another  Document. 

An  MMC  is  “eligible  for  relicensing”  if  it  is  licensed  under  this  License,  and  if  all  works  that  were  first  published  under  this  License 
somewhere  other  than  this  MMC,  and  subsequently  incorporated  in  whole  or  in  part  into  the  MMC,  (1)  had  no  cover  texts  or  invariant 
sections,  and  (2)  were  thus  incorporated  prior  to  November  1,  2008. 

The  operator  of  an  MMC  Site  may  republish  an  MMC  contained  in  the  site  under  CC-BY-SA  on  the  same  site  at  any  time  before 
August  1,  2009,  provided  the  MMC  is  eligible  for  relicensing. 
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